Architettura e Pattern nello Sviluppo Mobile: Cosa Sono, Quali Esistono e Come Applicarli

Principali Pattern Architetturali

Un pattern architetturale determina come le responsabilità sono distribuite tra le classi dell'applicazione. La scelta del pattern influisce sulla facilità di aggiungere nuovi schermi e testare il codice.

MVC (Model-View-Controller)

MVC è un pattern classico dove Model gestisce i dati, View la visualizzazione e Controller la logica. In iOS, MVC è il predefinito (UIViewController); in Android, Activity. Lo svantaggio è che il Controller diventa spesso "massiccio" (Massive View Controller). Secondo un sondaggio tra sviluppatori iOS (Reddit, 2025), il 62% indica MVC come la causa principale di codice illeggibile in progetti legacy.

MVP (Model-View-Presenter)

MVP si differenzia perché il Presenter gestisce la View tramite un'interfaccia, migliorando la testabilità. MVP era popolare in Android prima di Jetpack, ma è meno comodo di MVVM.

MVVM (Model-View-ViewModel)

MVVM è il pattern raccomandato da Google per Android e da Apple per iOS. Il ViewModel memorizza lo stato e la View si iscrive ai cambiamenti tramite Data Binding o @Published. Il ViewModel non dipende dalla View ed è facile da testare. In IT Sectr, usiamo MVVM come pattern principale in tutti i progetti.

MVI e VIPER

MVI è un pattern reattivo dove ogni azione segue il ciclo Intent → Model → View. MVI garantisce uno stato prevedibile. VIPER è un pattern iOS con cinque livelli (View, Interactor, Presenter, Entity, Router), che fornisce il massimo isolamento ma richiede molto codice boilerplate.

Clean Architecture

Clean Architecture è il concetto di Robert Martin che divide un'applicazione in livelli: i livelli esterni (UI, DB, rete) dipendono da quelli interni (logica di business, entità). Nello sviluppo mobile, Clean Architecture include tre livelli: data (repository), domain (Use Cases) e presentation (ViewModels, UI).

Repository Pattern è un componente chiave di Clean Architecture, che astrae la fonte dei dati. Il repository decide se recuperare i dati dalla rete o dall'archiviazione locale (Room, Core Data) e restituisce un formato unificato. Secondo Google (Architecture Guide, 2025), Repository Pattern è raccomandato per qualsiasi app con richieste di rete. Clean Architecture è giustificata in progetti con 3–5 schermi o più — per app semplici, inizia con MVVM.

Pattern Creazionali

Singleton

Singleton è un pattern architetturale che garantisce un'unica istanza di una classe e fornisce un punto di accesso globale ad essa. Viene usato per database, gestori di impostazioni e cache. In Kotlin, viene creato tramite object. Lo svantaggio è che complica i test a causa dello stato globale.

Factory e Builder

Factory delega la creazione di oggetti a un metodo factory — invece di new, chiami la factory. Builder è un pattern di costruzione passo-passo per oggetti complessi con molti parametri (AlertDialog.Builder, NotificationCompat.Builder). Builder migliora la leggibilità e permette agli oggetti di rimanere immutabili dopo l'assemblaggio.

Pattern Strutturali e Comportamentali

Adapter, Facade, Delegate, Protocol

Adapter è un pattern architetturale che converte l'interfaccia di una classe in un'interfaccia attesa dal cliente. In Android, è RecyclerView.Adapter. Facade fornisce un'interfaccia semplificata a un sistema complesso — per esempio, una facciata per un'API che nasconde i dettagli di autenticazione. Delegate è un pattern iOS dove un oggetto delega un compito (UITableViewDelegate). Protocol è l'equivalente di un'interfaccia in Swift.

Observer e Strategy

Observer è un pattern di iscrizione ai cambiamenti: il soggetto notifica gli iscritti degli aggiornamenti. Nello sviluppo mobile, Observer è la base di LiveData, StateFlow, RxJava e Combine. Strategy è un pattern di algoritmi intercambiabili: inserisci una strategia diversa (ordinamento, validazione) senza molteplici istruzioni if-else.

Iniezione di Dipendenze e Gestione dello Stato

Dependency Injection è un pattern architetturale dove un oggetto riceve le sue dipendenze dall'esterno invece di crearle lui stesso. Invece di new Database(), passi il database tramite il costruttore. DI semplifica i test — puoi usare un Mock invece di un database reale — e facilita lo scambio di implementazioni. Framework DI popolari: Dagger e Hilt (Android), Swinject (iOS), Koin (Kotlin). Hilt — un wrapper su Dagger raccomandato da Google — riduce la configurazione DI di 3 volte.

Service Locator è un'alternativa a DI con un registro centrale di dipendenze. Più semplice da implementare, ma nasconde le dipendenze della classe, rendendo i test più difficili. I progetti moderni preferiscono DI tramite Hilt o Koin.

Gestione dello Stato in Flutter

In Flutter, la gestione dello stato è un ecosistema a sé stante. Redux — un unico Store con cambiamenti tramite Actions → Reducer → State. BLoC di Google separa eventi e stati tramite Stream. Provider — un semplice contenitore DI raccomandato da Google per Flutter fino al 2023. Riverpod — un Provider migliorato che risolve problemi di compilazione e test. GetX — un micro-framework con routing, DI e gestione dello stato. Per sviluppatori Flutter principianti, raccomandiamo Provider o Riverpod come le soluzioni meglio documentate.

Principi SOLID e DRY

Oltre ai pattern specifici, esistono principi generali di progettazione architetturale applicabili in qualsiasi linguaggio e framework.

SOLID — cinque principi di progettazione orientata agli oggetti: Single Responsibility (una classe — un compito), Open-Closed (aperto all'estensione, chiuso alla modifica), Liskov Substitution (le sottoclassi sostituiscono la classe madre), Interface Segregation (interfacce piccole), Dependency Inversion (dipendere dalle astrazioni). Nello sviluppo mobile, SRP è il principio più utile: ogni classe fa solo una cosa. Secondo l'esperienza di IT Sectr, violare SRP è la causa del 70% dei problemi di test nei progetti commerciali.

// Пример: нарушение SRP
class UserManager {
    fun saveUser(user: User) { /* сохранение */ }
    fun validateEmail(email: String): Boolean { /* валидация */ }
    fun sendEmail(user: User) { /* отправка */ }
    fun formatUser(user: User): String { /* форматирование */ }
}

// Исправление: разделяем на отдельные классы
class UserRepository { fun save(user: User) {} }
class EmailValidator { fun isValid(email: String): Boolean {} }
class EmailService { fun send(user: User) {} }
class UserFormatter { fun format(user: User): String {} }

L'esempio Kotlin mostra come trasformiamo una classe UserManager con quattro responsabilità in quattro classi con una responsabilità ciascuna. Tale codice è più facile da testare, modificare e riutilizzare.

DRY (Don't Repeat Yourself) — evita la duplicazione del codice. Estrai la logica ripetuta in metodi o classi condivisi. KISS (Keep It Simple, Stupid) — la semplicità è più importante dell'eleganza. YAGNI (You Aren't Gonna Need It) — non scrivere codice per qualcosa che potrebbe non essere necessario. Questi principi aiutano a scrivere codice pulito e manutenibile senza ridondanza.

Pattern della Piattaforma Android

ViewModel (Android) è un componente dell'architettura Jetpack per memorizzare lo stato dell'UI, resistente alla rotazione dello schermo. ViewModel non contiene riferimenti ad Activity e viene pulito automaticamente. LiveData — un contenitore di dati osservabile con consapevolezza del ciclo di vita. StateFlow — un moderno sostituto di LiveData basato su Kotlin Flow. SharedFlow — un Hot Flow per eventi una tantum (navigazione, toast).

Data Binding e Two-Way Binding — meccanismi per legare UI e dati in Android. Data Binding dichiara la connessione in XML; Two-Way Binding aggiorna automaticamente il campo nel ViewModel. Unidirectional Data Flow — un principio dove i dati fluiscono in una direzione: State → UI → Event → State. In IT Sectr, usiamo Unidirectional Data Flow in tutti i nuovi progetti — riduce il numero di bug causati da cambiamenti di stato imprevisti.