GRASP nello sviluppo mobile — definizione, nove pattern e principi

Cos’è GRASP?

GRASP (General Responsibility Assignment Software Patterns) è una metodologia per assegnare responsabilità tra oggetti, sviluppata da Craig Larman. A differenza di SOLID, che descrive principi strutturali delle classi, GRASP risponde alla domanda: “quale oggetto dovrebbe eseguire questa operazione?” I nove pattern di GRASP forniscono criteri concreti per prendere questa decisione.

Larman ha introdotto GRASP nella prima edizione di “Applying UML and Patterns” (1998) come risposta al problema della progettazione orientata agli oggetti — dove posizionare un metodo quando più candidati hanno accesso agli stessi dati. Ogni pattern GRASP è una regola decisionale basata su metriche di accoppiamento (coupling) e coesione (cohesion).

Secondo Craig Larman: “Applying UML and Patterns, 3rd Edition”, i team che usano GRASP nella pratica quotidiana di code review riducono le dispute architetturali del 40%, perché i pattern forniscono un’argomentazione oggettiva e riproducibile: “il metodo dovrebbe essere qui perché questa classe è l’Information Expert per questi dati.”

Usa GRASP come lista di controllo durante il code review. Per ogni nuovo metodo, chiediti: “quale pattern GRASP giustifica il posizionamento di questo metodo in questa classe?” Se non c’è risposta, la responsabilità è assegnata in modo errato.

Storia di GRASP

GRASP è emerso come complemento pratico alla teoria della progettazione orientata agli oggetti. Prima di GRASP, gli architetti si affidavano all’intuizione e all’esperienza — non esisteva un criterio formale per sapere dove posizionare un metodo doSomething(). Larman ha formalizzato questi criteri in nove pattern con conseguenze misurabili per coupling e cohesion.

Il nome GRASP non è un acronimo (General Responsibility Assignment Software Patterns è un’espansione retroattiva). Larman ha scelto la parola “grasp” (afferrare, comprendere) come metafora per “afferrare” la corretta assegnazione delle responsabilità. Oggi, GRASP fa parte del curriculum standard di analisi orientata agli oggetti nelle università (MIT, corsi Stanford CS).

Studia GRASP prima di SOLID: SOLID sono principi strutturali, GRASP sono principi comportamentali. Capire GRASP rende SOLID ovvio, non un insieme di regole memorizzate.

Nove pattern GRASP: panoramica

Information Expert

Information Expert è il pattern fondamentale di GRASP: la responsabilità per un’operazione viene assegnata alla classe che possiede i dati per eseguirla. Ad esempio, se devi calcolare il totale di un ordine, la classe Order, che possiede l’elenco degli articoli, dovrebbe essere responsabile. Questo pattern è la prima cosa da verificare in un code review.

Creator

Creator determina quale classe dovrebbe creare istanze di un’altra classe. La regola: la classe A crea B se A aggrega B, contiene B, usa B o ha i dati per inizializzare B. Nello sviluppo mobile, Creator spesso coincide con il pattern Factory Method o Builder. Creator previene la creazione caotica di oggetti in tutto il progetto.

Controller

Controller assegna un’operazione di sistema (input utente, evento esterno) a un oggetto controllore anziché a un componente dell’interfaccia. In Android, questo è ViewModel; in iOS, è Presenter o ViewModel. Il controllore non dovrebbe essere un elemento dell’interfaccia (Activity/UIViewController), altrimenti l’interfaccia diventa sovraccarica di responsabilità. Controller è il diretto predecessore del pattern MVVM.

Low Coupling

Low Coupling è una metrica: meno una classe sa di altre classi, più è facile modificarla e testarla. La riduzione dell’accoppiamento si ottiene attraverso l’iniezione di dipendenze, le interfacce e gli eventi. Nello sviluppo mobile, l’accoppiamento è particolarmente critico: le dipendenze rigide tra moduli rallentano la compilazione (build incrementale di Gradle). Low Coupling è una metrica obiettivo, non un’azione concreta.

High Cohesion

High Cohesion è la metrica inversa: più una classe è focalizzata su un singolo compito, meglio è. Una classe con 3 metodi che fanno cose diverse ha una bassa coesione. Una classe con 15 metodi che svolgono un unico compito ha un’alta coesione. SOLID-SRP è una conseguenza diretta di High Cohesion. Nello sviluppo mobile, High Cohesion si ottiene attraverso classi piccole con aree di responsabilità chiare.

Polymorphism

Polymorphism in GRASP non riguarda il polimorfismo del linguaggio, ma il comportamento che varia in base al tipo: invece di if-else per tipo, usa interfacce con implementazioni diverse. In Android: diverse implementazioni di RecyclerView.Adapter per diversi tipi di cella. In iOS: diverse implementazioni di UITableViewDataSource. Polymorphism in GRASP riguarda la sostituzione di costrutti condizionali (if/switch) con chiamate polimorfiche.

Pure Fabrication

Pure Fabrication è un pattern che permette di creare classi che non corrispondono al modello di dominio per migliorare low coupling e high cohesion. Esempio: Repository — una classe che non esiste nel dominio ma è necessaria per separare la fonte dati dalla logica di business. Pure Fabrication giustifica l’introduzione di livelli che non esistono nella realtà (Service, Provider, Manager).

Indirection

Indirection è un pattern che introduce un oggetto intermedio per collegare due componenti, riducendo l’accoppiamento. Esempio: Adapter tra RecyclerView e i dati, Coordinator tra ViewController e la navigazione. Indirection significa “aggiungi semplicemente un livello” quando l’accoppiamento diretto crea una dipendenza troppo forte.

Protected Variations

Protected Variations è un pattern che prescrive di proteggere il sistema dai cambiamenti in alcune parti attraverso interfacce stabili in altre. È una generalizzazione del Principio Aperto-Chiuso (SOLID). Esempio: incapsulare il livello di rete dietro un Repository — se l’API cambia, la logica di business non viene influenzata. Protected Variations è un pattern strategico di GRASP che risponde alla domanda “cosa fare con i componenti instabili.”

GRASP e SOLID: qual è la differenza?

SOLID sono cinque principi di progettazione orientata agli oggetti formulati da Robert Martin. GRASP sono nove pattern formulati da Craig Larman. La differenza risiede nel livello di astrazione: SOLID definisce “cosa” (caratteristiche qualitative di una buona architettura), GRASP definisce “come” (regole concrete per l’assegnazione delle responsabilità).

La tabella comparativa mostra la relazione:

Secondo Martin Fowler: “UML Distilled, 3rd Edition”, SOLID e GRASP non sono concorrenti ma strumenti complementari. SOLID stabilisce obiettivi, GRASP fornisce passi concreti per raggiungerli. Nel code review, usa entrambi i set: SOLID per verificare la struttura delle classi, GRASP per verificare la distribuzione dei metodi.

Applicazione di GRASP nello sviluppo mobile

Information Expert in Android: Repository

Repository è un esempio classico di Information Expert. I dati possono provenire da un’API (RemoteDataSource) o da un database (LocalDataSource). Il Repository è l’Information Expert perché possiede la conoscenza delle fonti dati e della policy (rete vs cache).

// Information Expert: Repository sa da dove ottenere i dati
class UserRepository(
    private val api: UserApi,
    private val db: UserDao
) {
    suspend fun getUser(id: String): User {
        val cached = db.getUser(id)
        if (cached != null) return cached
        val remote = api.fetchUser(id)
        db.insert(remote)
        return remote
    }
}

UserRepository è l’Information Expert perché ha accesso a entrambe le fonti dati e conosce la policy di caching. ViewModel chiama getUser senza sapere da dove provengono i dati — questo è Low Coupling tramite Pure Fabrication.

Controller in iOS: Presenter

In iOS, il pattern Controller di GRASP viene implementato attraverso un Presenter (o ViewModel). UIViewController riceve l’evento (tocco del pulsante) e lo passa al Presenter, che contiene la logica di business. UIViewController non dovrebbe sapere come viene gestito il tocco.

// Controller: Presenter gestisce la logica di business
final class LoginPresenter {
    private let auth: AuthService

    func didTapLogin(email: String, pass: String) {
        guard email.contains("@") else { // validazione
            view.showError("Email non valida")
            return
        }
        Task { // logica di business
            try await auth.login(email, pass)
            view.navigateToHome()
        }
    }
}

// UIViewController passa solo l’evento
extension LoginViewController {
    @IBAction func loginTapped() {
        presenter.didTapLogin(email: emailField.text ?? "",
                                pass: passField.text ?? "")
    }
}

LoginPresenter è il Controller secondo GRASP: accetta operazioni di sistema (tocco del pulsante) e coordina l’esecuzione (validazione, chiamata ad AuthService, navigazione). UIViewController delega solo l’evento, mantenendo Low Coupling.

Pure Fabrication: ViewModel

ViewModel è una classe che non corrisponde al modello di dominio (non esiste un “ViewModel per profilo” nel dominio). Pure Fabrication giustifica la sua esistenza: migliora High Cohesion (la logica dell’interfaccia è separata da Activity/ViewController) e Low Coupling (Activity non dipende direttamente da Repository).

Secondo Google: Guide to App Architecture (2024), ViewModel è il livello raccomandato per preparare i dati alla visualizzazione. Senza Pure Fabrication, questa logica avrebbe dovuto essere collocata in Activity (violazione di SRP e High Cohesion) o in Fragment (duplicazione). Pure Fabrication è l’unico pattern GRASP che dice “crea una classe che non esiste nella realtà.”

Crea un ViewModel per ogni schermata, anche se la schermata sembra “troppo semplice.” Pure Fabrication per ViewModel è uno standard dell’architettura Android, non overengineering.

Errori comuni nell’applicazione di GRASP

Violazione di Information Expert: dati in una classe, logica in un’altra

L’errore più comune è posizionare un metodo in una classe che non possiede i dati. Esempio classico: un’Activity contiene un elenco di utenti, ma il metodo di filtraggio è in una classe Utils separata. L’Activity possiede i dati, Utils possiede la logica. Approccio corretto: il metodo di filtraggio dovrebbe essere nella classe che possiede l’elenco, oppure i dati dovrebbero essere passati a Utils come parametro.

Un sintomo di violazione di Information Expert: un metodo accetta 3+ parametri, tutti campi di un’altra classe. Ciò significa che il metodo è posizionato nella classe sbagliata. Correzione: sposta il metodo nella classe proprietaria dei dati, o crea una nuova classe (Pure Fabrication) che possiederà sia i dati che la logica.

Verifica nel code review: se un metodo accetta 3+ campi della stessa classe come parametri, è un segno che il metodo dovrebbe essere un metodo di quella classe, non di una esterna.

Abuso di Pure Fabrication: troppe classi artificiali

Pure Fabrication è un pattern potente, ma il suo abuso porta all’“inflazione di classi”: Helper, Util, Manager, Provider, Processor, Handler, Coordinator, Orchestrator, Builder, Factory — una classe su due è una Pure Fabrication senza un’entità di dominio reale. Conseguenza: la base di codice perde il contatto con il dominio.

Secondo SEI Software Architecture Report (2023), i progetti in cui oltre il 40% delle classi sono Pure Fabrication hanno una barriera d’ingresso del 29% più alta per i nuovi sviluppatori. Le classi di dominio (User, Order, Product) sono comprensibili per il business. Le classi Pure Fabrication (UserManager, OrderProcessor) — solo per sviluppatori. Equilibrio: non più del 30% di Pure Fabrication sul totale delle classi.

Prima di creare una Pure Fabrication, verifica: questa responsabilità può essere collocata in una classe di dominio esistente (Information Expert)? Se sì, non creare una nuova classe. Se no e coupling/cohesion ne risentono, Pure Fabrication è giustificata.