GRASP inom mobil utveckling — vad det är, nio mönster och principer

Vad är GRASP?

GRASP (General Responsibility Assignment Software Patterns) — en metodik för ansvarsfördelning mellan objekt som utvecklats av Craig Larman. Till skillnad från SOLID, som beskriver strukturella principer för klasser, svarar GRASP på frågan: "vilket objekt ska utföra denna operation?" Nio mönster i GRASP ger konkreta kriterier för beslutsfattande.

Larman introducerade GRASP i den första upplagan av "Applying UML and Patterns" (1998) som ett svar på problemet med objektorienterad design — var ska man placera en metod när flera kandidater har tillgång till samma data. Varje mönster i GRASP är en beslutsregel baserad på mått på koppling (coupling) och sammanhållning (cohesion).

Enligt Craig Larman: "Applying UML and Patterns, 3rd Edition", minskar team som använder GRASP i daglig code review-praktik antalet arkitektoniska tvister med 40%, eftersom mönstren ger objektiv, reproducerbar argumentation: "metoden bör vara här, eftersom denna klass är Information Expert för denna data".

Använd GRASP som checklista vid code review. För varje ny metod, ställ frågan: "vilket GRASP-mönster motiverar att placera denna metod just i denna klass?" Om det inte finns något svar — är ansvaret felaktigt fördelat.

Historien om GRASPs uppkomst

GRASP uppstod som ett praktiskt komplement till teorin om objektorienterad design. Före GRASP förlitade sig arkitekter på intuition och erfarenhet — det fanns inget formellt kriterium för var man skulle placera metoden doSomething(). Larman formaliserade dessa kriterier i form av nio mönster med mätbara konsekvenser för coupling och cohesion.

Namnet GRASP — är ingen akronym (General Responsibility Assignment Software Patterns — efterhandsförklaring). Larman valde ordet "grasp" (grepp, förståelse) som en metafor för att "greppa" rätt ansvarsfördelning. Nu ingår GRASP i standardkursen i objektorienterad analys vid universitet (MIT, Stanford CS-kurser).

Lär dig GRASP före SOLID: SOLID — strukturella principer, GRASP — beteendeprinciper. Att förstå GRASP gör SOLID självklart, inte en uppsättning regler att memorera.

Nio GRASP-mönster: översikt

Information Expert

Information Expert — grundmönstret i GRASP: ansvaret för en operation tilldelas den klass som har data för att utföra den. Till exempel, om summan av en beställning ska beräknas — kommer klassen Order som har listan över artiklar att vara ansvarig. Detta mönster — det första att kontrollera vid code review.

Creator

Creator bestämmer vilken klass som ska skapa instanser av en annan klass. Regel: klass A skapar B om A aggregerar B, innehåller B, använder B eller har data för initiering av B. Inom mobil utveckling sammanfaller Creator ofta med fabriksmetoden eller Builder-mönstret. Creator förhindrar kaotisk objektskapelse i hela projektet.

Controller

Controller tilldelar systemoperationen (användarinmatning, extern händelse) till ett kontrollobjekt, inte till en UI-komponent. I Android är detta ViewModel, i iOS — Presenter eller ViewModel. Kontrollobjektet bör inte vara ett UI-element (Activity/UIViewController), annars blir UI överbelastat med ansvar. Controller — den direkta föregångaren till MVVM-mönstret.

Low Coupling

Low Coupling — mått: ju mindre en klass vet om andra klasser, desto lättare är den att ändra och testa. Minskning av coupling uppnås genom beroendeinjektion, gränssnitt och händelser. Inom mobil utveckling är coupling särskilt kritisk: stela förbindelser mellan moduler saktar ner kompileringen (Gradle incremental build). Låg koppling — måttmål, inte en konkret åtgärd.

High Cohesion

High Cohesion — omvänt mått: ju mer fokuserad en klass är på en uppgift, desto bättre. En klass med 3 metoder som gör olika saker har låg sammanhållning. En klass med 15 metoder som utför en uppgift — hög sammanhållning. SOLID-SRP — direkt följd av High Cohesion. Inom mobil utveckling uppnås High Cohesion genom små klasser med tydligt ansvarsområde.

Polymorphism

Polymorphism i GRASP — handlar inte om språkets polymorfism, utan om beteende som varierar efter typ: istället för if-else efter typ, använd gränssnitt med olika implementeringar. I Android: olika implementeringar av RecyclerView.Adapter för olika celltyper. I iOS: olika implementeringar av UITableViewDataSource. Polymorphism i GRASP — om att ersätta villkorskonstruktioner (if/switch) med polymorfa anrop.

Pure Fabrication

Pure Fabrication — mönster som tillåter skapande av klasser som inte överensstämmer med domänmodellen för att förbättra low coupling och high cohesion. Exempel: Repository — en klass som inte finns i problemdomänen, men som behövs för att separera datakällan från affärslogiken. Pure Fabrication motiverar införandet av lager som inte finns i verkligheten (Service, Provider, Manager).

Indirection

Indirection — mönster som introducerar ett mellanliggande objekt för kommunikation mellan två komponenter, vilket minskar coupling. Exempel: Adapter mellan RecyclerView och data, Coordinator mellan ViewController och navigering. Indirection — betyder "lägg bara till ett mellanlager" när direkt anslutning skapar en alltför stark koppling.

Protected Variations

Protected Variations — mönster som föreskriver skydd av systemet mot förändringar i vissa delar genom stabila gränssnitt i andra delar. Detta är en generalisering av Open-Closed Principle (SOLID). Exempel: inkapsling av nätverkslagret bakom Repository — om API:et ändras påverkas inte affärslogiken. Protected Variations — det strategiska GRASP-mönstret som svarar på frågan "vad ska man göra med instabila komponenter".

GRASP och SOLID: vad är skillnaden?

SOLID — fem principer för objektorienterad design formulerade av Robert Martin. GRASP — nio mönster formulerade av Craig Larman. Skillnaden ligger i abstraktionsnivån: SOLID — vad (kvalitativa egenskaper hos bra arkitektur), GRASP — hur (konkreta regler för ansvarsfördelning).

Jämförelsetabellen visar sambandet:

Enligt Martin Fowler: "UML Distilled, 3rd Edition" är SOLID och GRASP inte konkurrenter, utan kompletterande verktyg. SOLID sätter mål, GRASP — konkreta steg för att uppnå dem. Vid code review, använd båda uppsättningarna: SOLID för att kontrollera klassstrukturen, GRASP för att kontrollera metodfördelningen.

Tillämpning av GRASP inom mobil utveckling

Information Expert i Android: Repository

Repository — ett klassiskt exempel på Information Expert. Data kan komma från API (RemoteDataSource) eller från databas (LocalDataSource). Repositoriet är Information Expert eftersom det har information om datakällor och policy (nätverk vs cache).

// Information Expert: Repository vet var data ska hämtas
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 är Information Expert eftersom det har tillgång till båda datakällorna och känner till cachningspolicyn. ViewModel anropar getUser utan att veta var data kommer ifrån — detta är Low Coupling genom Pure Fabrication.

Controller i iOS: Presenter

I iOS implementeras Controller GRASP-mönstret via Presenter (eller ViewModel). UIViewController tar emot händelsen (knapptryckning) och vidarebefordrar den till Presenter som innehåller affärslogiken. UIViewController bör inte veta hur knapptryckningen bearbetas.

// Controller: Presenter bearbetar affärslogiken
final class LoginPresenter {
    private let auth: AuthService

    func didTapLogin(email: String, pass: String) {
        guard email.contains("@") else { // validering
            view.showError("Ogiltig e-post")
            return
        }
        Task { // affärslogik
            try await auth.login(email, pass)
            view.navigateToHome()
        }
    }
}

// UIViewController vidarebefordrar endast händelsen
extension LoginViewController {
    @IBAction func loginTapped() {
        presenter.didTapLogin(email: emailField.text ?? "",
                                pass: passField.text ?? "")
    }
}

LoginPresenter är Controller enligt GRASP: den tar emot systemoperationer (knapptryckning) och samordnar utförandet (validering, anrop till AuthService, navigering). UIViewController — delegerar bara händelsen och bibehåller Low Coupling.

Pure Fabrication: ViewModel

ViewModel — en klass som inte överensstämmer med domänmodellen (i problemdomänen finns ingen "ViewModel för profil"). Pure Fabrication motiverar dess existens: den förbättrar High Cohesion (UI-logik separeras från Activity/ViewController) och Low Coupling (Activity är inte direkt beroende av Repository).

Enligt Google: Guide to App Architecture (2024) är ViewModel det rekommenderade lagret för att förbereda data för visning. Utan Pure Fabrication skulle denna logik behöva placeras i Activity (brott mot SRP och High Cohesion) eller i Fragment (duplicering). Pure Fabrication — det enda GRASP-mönstret som säger "skapa en klass som inte finns i verkligheten".

Skapa ViewModel för varje skärm, även om skärmen verkar "för enkel". Pure Fabrication för ViewModel — standarden för Android-arkitektur, inte överdriven design.

Vanliga misstag vid tillämpning av GRASP

Brott mot Information Expert: data i en klass, logik — i en annan

Det vanligaste misstaget — att placera metoden i den klass som inte äger data. Klassiskt: Activity innehåller listan över användare, men filtreringsmetoden — i en separat Utils-klass. Activity äger data, Utils — logiken. Rätt: filtreringsmetoden bör vara i den klass som äger listan eller så bör data skickas till Utils som parameter.

Symptom på brott mot Information Expert: metoden tar emot 3+ parametrar, alla är fält från en annan klass. Det betyder att metoden är placerad i fel klass. Åtgärd: flytta metoden till den klass som äger data eller skapa en ny klass (Pure Fabrication) som kommer att äga både data och logik.

Kontrollera vid code review: om en metod tar emot 3+ fält från samma klass som parametrar — är detta ett tecken på att metoden borde vara en metod i den klassen, inte en extern.

Missbruk av Pure Fabrication: för många artificiella klasser

Pure Fabrication — ett kraftfullt mönster, men missbruk av det leder till "klassinflation": Helper, Util, Manager, Provider, Processor, Handler, Coordinator, Orchestrator, Builder, Factory — varannan klass är Pure Fabrication utan verklig domänmotsvarighet. Konsekvens: kodbasen förlorar kopplingen till problemdomänen.

Enligt SEI Software Architecture Report (2023) har projekt där mer än 40% av klasserna är Pure Fabrication en 29% högre inträdes tröskel för nya utvecklare. Domänklasser (User, Order, Product) är förståeliga för verksamheten. Pure Fabrication-klasser (UserManager, OrderProcessor) — endast för utvecklare. Balans: inte mer än 30% Pure Fabrication av det totala antalet klasser.

Innan du skapar Pure Fabrication, kontrollera: kan detta ansvar placeras i en befintlig domänklass (Information Expert)? Om ja — skapa inte en ny klass. Om nej och coupling/cohesion lider — är Pure Fabrication motiverat.