Separation of Concerns nello sviluppo mobile — cos'è, principi e applicazione

Cos'è Separation of Concerns

Separation of Concerns è un principio di scomposizione di un sistema software in parti indipendenti, ciascuna delle quali risolve un compito. Il termine concern (area di responsabilità) designa qualsiasi parte separabile della funzionalità: visualizzazione dello schermo, gestione dei tocchi, validazione dei dati o comunicazione di rete. Il principio prescrive di raggruppare il codice in modo che le modifiche in un'area non richiedano modifiche in altre.

Nello sviluppo mobile, SoC si manifesta a più livelli: dalla suddivisione dell'applicazione in schermate all'organizzazione del codice all'interno di una singola classe. Una Activity o ViewController che carica contemporaneamente dati dalla rete, analizza JSON e renderizza l'UI viola Separation of Concerns — tale codice è difficile da mantenere, testare ed estendere. L'alternativa è estrarre ogni responsabilità in un componente separato.

Il principio è strettamente legato al concetto di astrazione: ogni livello fornisce un'interfaccia rigorosamente definita e nasconde i dettagli implementativi. Grazie a ciò, uno sviluppatore può sostituire una libreria di rete o un database senza riscrivere la logica dell'UI. Questo è particolarmente prezioso in progetti di lunga durata dove requisiti e tecnologie cambiano nel tempo.

Storia e origine del principio

Edsger Dijkstra formulò per la prima volta l'idea di Separation of Concerns nel suo articolo del 1974 «On the Role of Scientific Thought». Sosteneva che la complessità dei sistemi software può essere controllata dividendoli in parti che vengono analizzate isolatamente. Questo approccio contrastava con i programmi monolitici dell'epoca, dove il codice mescolava calcolo, I/O e interfaccia utente.

Negli anni '80, l'idea fu sviluppata dai sostenitori della programmazione strutturata e successivamente dall'approccio orientato agli oggetti. Linguaggi come Smalltalk e C++ fornirono meccanismi di incapsulamento e modularità che resero SoC uno strumento pratico. I pattern architetturali moderni — MVC, MVP, MVVM e Clean Architecture — sono incarnazioni dirette del principio Separation of Concerns.

Nel mondo dello sviluppo mobile, Apple ha promosso MVC come standard per iOS, dove Model-View-Controller separa dati, visualizzazione e logica di controllo. Google per Android ha proposto linee guida architetturali basate su ViewModel e Repository — ogni componente risolve il suo specifico compito. Senza SoC, le applicazioni mobili si trasformano in Massive View Controller — classi con migliaia di righe dove qualsiasi modifica rischia di rompere l'intera funzionalità.

Livelli di separazione nell'architettura mobile

Quattro livelli principali formano un'architettura tipica di applicazione mobile che implementa Separation of Concerns. Ogni livello è responsabile solo del proprio dominio e interagisce con i vicini attraverso interfacce.

Livello UI: View e ViewModel

View è responsabile esclusivamente della visualizzazione dei dati e della gestione degli eventi utente. In iOS sono UIViewController e UIView, in Android — Fragment o Activity. ViewModel contiene lo stato dello schermo e la logica per trasformare i dati in un formato pronto per la visualizzazione. La separazione garantisce che la sostituzione di UIKit con SwiftUI o la riscrittura di uno schermo con Jetpack Compose non influisca sulla logica di business.

Testare ViewModel non richiede l'esecuzione di un emulatore o simulatore — sono sufficienti test unitari che verificano la trasformazione dei dati e la risposta alle azioni dell'utente. Questa è una conseguenza diretta di Separation of Concerns: l'UI non viene mescolata con le regole di business e ogni componente viene testato isolatamente.

Livello di logica di business: Casi d'uso e Interactor

Il Caso d'uso (o Interactor) contiene le regole di business dell'applicazione — calcoli, validazioni, orchestrazione delle chiamate ai dati. Questo livello non conosce l'esistenza dell'UI o dei framework della piattaforma. Il Caso d'uso riceve i dati dal Repository, applica loro la logica e restituisce il risultato finale a ViewModel. La separazione consente di riutilizzare lo stesso Caso d'uso su schermate diverse.

Ad esempio, LoginUseCase verifica la validità dell'email, chiama AuthRepository per l'autenticazione e restituisce il risultato. Non dipende dall'aspetto della schermata di login — SwiftUI, UIKit o Compose. Se le regole di business cambiano, è sufficiente modificare un Caso d'uso senza toccare l'UI o il database.

Livello dati: Repository e DataSource

Repository astrae le fonti di dati: API remota, database locale o cache in memoria. ViewModel e Caso d'uso non sanno da dove provengono esattamente i dati — Repository decide se caricare dalla rete o dalla cache. Questa separazione consente di cambiare l'implementazione dell'archiviazione senza influenzare la logica di business o l'UI.

DataSource è una separazione ancora più di basso livello: NetworkDataSource è responsabile solo delle richieste HTTP, LocalDataSource — di lavorare con Room o CoreData. Repository combina le chiamate a diversi DataSources in un'unica interfaccia coerente. Ogni DataSource viene testato indipendentemente utilizzando mock o server fittizi.

La corretta implementazione del livello DataSource garantisce che la modifica dello schema del database o la sostituzione di REST API con GraphQL influisca solo su un DataSource, ma non sul Repository o sui suoi consumatori. Questa è una conseguenza diretta di Separation of Concerns a livello di infrastruttura: ogni preoccupazione tecnica è isolata e sostituibile senza modifiche a cascata.

SoC nei pattern di progettazione

MVVM (Model-View-ViewModel) è il pattern più popolare per lo sviluppo mobile, che implementa direttamente Separation of Concerns. Model contiene dati e logica di business, View è responsabile della visualizzazione e ViewModel li collega attraverso meccanismi reattivi. In Flutter, BLoC svolge un ruolo simile con separazione in eventi, stati e logica di business.

Clean Architecture di Robert Martin (Uncle Bob) porta SoC al massimo: il sistema è diviso in anelli indipendenti — entità, casi d'uso, adapter e framework. Gli anelli interni (entità) non dipendono da quelli esterni (framework). Ciò consente di cambiare database, framework UI e persino piattaforma senza riscrivere la logica centrale dell'applicazione.

In pratica, i progetti mobili raramente implementano la Clean Architecture completa — per la maggior parte delle applicazioni è sufficiente un'architettura a tre livelli: UI, Dominio e Dati. Il livello Dominio contiene Casi d'uso e modelli di business ed è completamente isolato da Android SDK o iOS SDK. Tale separazione offre l'80% del beneficio con il 20% dello sforzo.

// Data layer — responsabile solo del recupero dati
class UserRepository(private val api: UserApi) {
    suspend fun getUser(id: String): User = api.fetchUser(id)
}

// Domain layer — logica di business, non conosce API o database
class GetUserNameUseCase(
    private val repo: UserRepository
) {
    suspend fun invoke(id: String): String {
        val user = repo.getUser(id)
        return "${user.firstName} ${user.lastName}"
    }
}

// UI layer — solo visualizzazione
class UserViewModel(
    private val getUserName: GetUserNameUseCase
) {
    fun onUserLoaded(id: String) {
        viewModelScope.launch {
            _name.value = getUserName.invoke(id)
        }
    }
}

Il codice sopra dimostra una separazione pura: UserRepository lavora solo con l'API, GetUserNameUseCase contiene la logica di business per formattare il nome e UserViewModel gestisce lo stato dell'UI. Ogni classe ha una ragione per cambiare, che è l'essenza di Separation of Concerns.

Vantaggi e limiti di Separation of Concerns

Il principale vantaggio di SoC è la manutenibilità. Il codice diviso in livelli indipendenti è più facile da analizzare: lo sviluppatore guarda solo il livello in cui si verifica l'errore e non viene distratto dagli altri. Nei progetti a lungo termine, ciò riduce il tempo di ricerca e correzione dei bug del 30–50% rispetto al codice monolitico.

Il secondo importante vantaggio è la testabilità. Quando la logica di business è isolata dall'UI e dai framework, viene coperta da test unitari senza eseguire un emulatore. I progetti Android e iOS con un'elevata copertura di test unitari hanno significativamente meno regressioni quando si aggiungono nuove funzionalità.

Il limite principale è l'aumento della complessità. La frammentazione eccessiva in micro-livelli e astrazioni porta al fatto che per aggiungere un semplice pulsante lo sviluppatore deve modificare cinque file. Il principio Separation of Concerns richiede un equilibrio ragionevole: separare solo quelle aree che cambiano realmente in modo indipendente. Per i progetti piccoli, una separazione di base in UI, logica e dati senza astrazioni aggiuntive è sufficiente.