GRASP in der mobilen Entwicklung — was es ist, neun Pattern und Prinzipien

Was ist GRASP?

GRASP (General Responsibility Assignment Software Patterns) ist eine Methodik zur Zuweisung von Verantwortlichkeiten zwischen Objekten, entwickelt von Craig Larman. Im Gegensatz zu SOLID, das strukturelle Prinzipien von Klassen beschreibt, beantwortet GRASP die Frage: „Welches Objekt sollte diese Operation ausführen?“ Die neun Pattern von GRASP liefern konkrete Kriterien für diese Entscheidung.

Larman führte GRASP in der ersten Ausgabe von „Applying UML and Patterns“ (1998) als Antwort auf das Problem des objektorientierten Designs ein — wo platziert man eine Methode, wenn mehrere Kandidaten Zugriff auf dieselben Daten haben? Jedes GRASP-Pattern ist eine Entscheidungsregel basierend auf Metriken von Kopplung (coupling) und Kohäsion (cohesion).

Laut Craig Larman: „Applying UML and Patterns, 3rd Edition“ reduzieren Teams, die GRASP in der täglichen Code-Review-Praxis verwenden, Architekturstreitigkeiten um 40%, weil die Pattern eine objektive, reproduzierbare Argumentation liefern: „Die Methode sollte hier sein, weil diese Klasse der Information Expert für diese Daten ist.“

Verwenden Sie GRASP als Checkliste bei der Code-Review. Fragen Sie bei jeder neuen Methode: „Welches GRASP-Pattern rechtfertigt die Platzierung dieser Methode in dieser Klasse?“ Wenn es keine Antwort gibt, ist die Verantwortung falsch zugewiesen.

Geschichte von GRASP

GRASP entstand als praktische Ergänzung zur Theorie des objektorientierten Designs. Vor GRASP verließen sich Architekten auf Intuition und Erfahrung — es gab kein formales Kriterium, wo eine doSomething()-Methode zu platzieren ist. Larman formalisierte diese Kriterien in neun Pattern mit messbaren Konsequenzen für Kopplung und Kohäsion.

Der Name GRASP ist kein Akronym (General Responsibility Assignment Software Patterns ist eine Rückwärtsexpansion). Larman wählte das Wort „grasp“ (ergreifen, verstehen) als Metapher für das „Ergreifen“ der richtigen Verantwortungszuweisung. Heute ist GRASP Teil des standardmäßigen Curriculums für objektorientierte Analyse an Universitäten (MIT, Stanford CS-Kurse).

Studieren Sie GRASP vor SOLID: SOLID sind strukturelle Prinzipien, GRASP sind Verhaltensprinzipien. GRASP zu verstehen macht SOLID offensichtlich, nicht zu einem Satz auswendig gelernter Regeln.

Neun GRASP-Pattern: Überblick

Information Expert

Information Expert ist das grundlegende GRASP-Muster: Die Verantwortung für eine Operation wird der Klasse zugewiesen, die die Daten zu ihrer Ausführung hat. Wenn Sie beispielsweise den Gesamtbetrag einer Bestellung berechnen müssen, sollte die Klasse Order, die die Liste der Artikel besitzt, verantwortlich sein. Dieses Muster ist das Erste, was bei einer Code-Review zu überprüfen ist.

Creator

Creator bestimmt, welche Klasse Instanzen einer anderen Klasse erstellen soll. Die Regel: Klasse A erzeugt B, wenn A B aggregiert, B enthält, B verwendet oder die Daten zur Initialisierung von B hat. In der mobilen Entwicklung stimmt Creator oft mit dem Factory-Method- oder Builder-Muster überein. Creator verhindert chaotische Objekterstellung im gesamten Projekt.

Controller

Controller weist eine Systemoperation (Benutzereingabe, externes Ereignis) einem Controller-Objekt zu, nicht einer UI-Komponente. In Android ist dies ViewModel, in iOS ist es Presenter oder ViewModel. Der Controller sollte kein UI-Element (Activity/UIViewController) sein, sonst wird die UI mit Verantwortung überladen. Controller ist der direkte Vorläufer des MVVM-Musters.

Low Coupling

Low Coupling ist eine Metrik: Je weniger eine Klasse über andere Klassen weiß, desto einfacher ist sie zu ändern und zu testen. Die Reduzierung der Kopplung wird durch Abhängigkeitsinjektion, Schnittstellen und Ereignisse erreicht. In der mobilen Entwicklung ist die Kopplung besonders kritisch: Starre Abhängigkeiten zwischen Modulen verlangsamen die Kompilierung (Gradle inkrementeller Build). Low Coupling ist eine Zielmetrik, keine konkrete Aktion.

High Cohesion

High Cohesion ist die umgekehrte Metrik: Je fokussierter eine Klasse auf eine einzelne Aufgabe ist, desto besser. Eine Klasse mit 3 Methoden, die verschiedene Dinge tun, hat eine niedrige Kohäsion. Eine Klasse mit 15 Methoden, die eine Aufgabe erfüllen, hat eine hohe Kohäsion. SOLID-SRP ist eine direkte Folge von High Cohesion. In der mobilen Entwicklung wird High Cohesion durch kleine Klassen mit klaren Verantwortungsbereichen erreicht.

Polymorphism

Polymorphism in GRASP handelt nicht vom Sprachpolymorphismus, sondern vom Verhalten, das je nach Typ variiert: Statt if-else nach Typ verwenden Sie Schnittstellen mit verschiedenen Implementierungen. In Android: verschiedene RecyclerView.Adapter-Implementierungen für verschiedene Zelltypen. In iOS: verschiedene UITableViewDataSource-Implementierungen. Polymorphism in GRASP handelt davon, bedingte Konstrukte (if/switch) durch polymorphe Aufrufe zu ersetzen.

Pure Fabrication

Pure Fabrication ist ein Muster, das die Erstellung von Klassen erlaubt, die nicht dem Domänenmodell entsprechen, um Low Coupling und High Cohesion zu verbessern. Beispiel: Repository — eine Klasse, die in der Domäne nicht existiert, aber benötigt wird, um die Datenquelle von der Geschäftslogik zu trennen. Pure Fabrication rechtfertigt die Einführung von Schichten, die in der Realität nicht existieren (Service, Provider, Manager).

Indirection

Indirection ist ein Muster, das ein Zwischenobjekt einführt, um zwei Komponenten zu verbinden und die Kopplung zu reduzieren. Beispiel: Adapter zwischen RecyclerView und Daten, Coordinator zwischen ViewController und Navigation. Indirection bedeutet „füge einfach eine Schicht hinzu“, wenn die direkte Kopplung eine zu starke Abhängigkeit erzeugt.

Protected Variations

Protected Variations ist ein Muster, das vorschreibt, das System vor Änderungen in einigen Teilen durch stabile Schnittstellen in anderen zu schützen. Dies ist eine Verallgemeinerung des Open-Closed-Prinzips (SOLID). Beispiel: Kapselung der Netzwerkschicht hinter einem Repository — wenn sich die API ändert, wird die Geschäftslogik nicht beeinträchtigt. Protected Variations ist ein strategisches GRASP-Muster, das die Frage „was tun mit instabilen Komponenten“ beantwortet.

GRASP und SOLID: Was ist der Unterschied?

SOLID sind fünf objektorientierte Designprinzipien, formuliert von Robert Martin. GRASP sind neun Pattern, formuliert von Craig Larman. Der Unterschied liegt in der Abstraktionsebene: SOLID definiert das „Was“ (qualitative Merkmale einer guten Architektur), GRASP definiert das „Wie“ (konkrete Regeln zur Verantwortungszuweisung).

Die Vergleichstabelle zeigt die Beziehung:

Laut Martin Fowler: „UML Distilled, 3rd Edition“ sind SOLID und GRASP keine Konkurrenten, sondern sich ergänzende Werkzeuge. SOLID setzt Ziele, GRASP liefert konkrete Schritte zu deren Erreichung. Verwenden Sie bei der Code-Review beide Sätze: SOLID zur Überprüfung der Klassenstruktur, GRASP zur Überprüfung der Methodenverteilung.

Anwendung von GRASP in der mobilen Entwicklung

Information Expert in Android: Repository

Repository ist ein klassisches Beispiel für Information Expert. Daten können von einer API (RemoteDataSource) oder einer Datenbank (LocalDataSource) kommen. Das Repository ist der Information Expert, weil es das Wissen über Datenquellen und die Richtlinie (Netzwerk vs. Cache) besitzt.

// Information Expert: Repository weiß, woher Daten zu beziehen sind
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 ist der Information Expert, weil es Zugriff auf beide Datenquellen hat und die Caching-Richtlinie kennt. ViewModel ruft getUser auf, ohne zu wissen, woher die Daten kamen — das ist Low Coupling durch Pure Fabrication.

Controller in iOS: Presenter

In iOS wird das Controller-GRASP-Muster durch einen Presenter (oder ViewModel) implementiert. UIViewController empfängt das Ereignis (Schaltflächentipp) und leitet es an den Presenter weiter, der die Geschäftslogik enthält. UIViewController sollte nicht wissen, wie der Tipp behandelt wird.

// Controller: Presenter verarbeitet die Geschäftslogik
final class LoginPresenter {
    private let auth: AuthService

    func didTapLogin(email: String, pass: String) {
        guard email.contains("@") else { // Validierung
            view.showError("Ungültige E-Mail")
            return
        }
        Task { // Geschäftslogik
            try await auth.login(email, pass)
            view.navigateToHome()
        }
    }
}

// UIViewController leitet nur das Ereignis weiter
extension LoginViewController {
    @IBAction func loginTapped() {
        presenter.didTapLogin(email: emailField.text ?? "",
                                pass: passField.text ?? "")
    }
}

LoginPresenter ist der Controller nach GRASP: Er nimmt Systemoperationen (Schaltflächentipp) an und koordiniert die Ausführung (Validierung, Aufruf von AuthService, Navigation). UIViewController delegiert nur das Ereignis und behält so Low Coupling bei.

Pure Fabrication: ViewModel

ViewModel ist eine Klasse, die nicht dem Domänenmodell entspricht (es gibt kein „ViewModel für Profil“ in der Domäne). Pure Fabrication rechtfertigt seine Existenz: Es verbessert High Cohesion (UI-Logik ist von Activity/ViewController getrennt) und Low Coupling (Activity hängt nicht direkt vom Repository ab).

Laut Google: Guide to App Architecture (2024) ist ViewModel die empfohlene Schicht zur Aufbereitung von Daten für die Anzeige. Ohne Pure Fabrication müsste diese Logik in Activity (Verletzung von SRP und High Cohesion) oder in Fragment (Duplizierung) platziert werden. Pure Fabrication ist das einzige GRASP-Muster, das sagt „Erstelle eine Klasse, die in der Realität nicht existiert.“

Erstellen Sie ein ViewModel für jeden Bildschirm, auch wenn der Bildschirm „zu einfach“ erscheint. Pure Fabrication für ViewModel ist ein Standard der Android-Architektur, keine Übertechnisierung.

Häufige Fehler bei der Anwendung von GRASP

Verletzung von Information Expert: Daten in einer Klasse, Logik in einer anderen

Der häufigste Fehler ist das Platzieren einer Methode in einer Klasse, die nicht die Daten besitzt. Klassisches Beispiel: Eine Activity enthält eine Liste von Benutzern, aber die Filtermethode ist in einer separaten Utils-Klasse. Die Activity besitzt die Daten, Utils besitzt die Logik. Richtiger Ansatz: Die Filtermethode sollte in der Klasse sein, die die Liste besitzt, oder die Daten sollten als Parameter an Utils übergeben werden.

Ein Symptom der Verletzung von Information Expert: Eine Methode nimmt 3+ Parameter entgegen, die alle Felder einer anderen Klasse sind. Das bedeutet, die Methode ist in der falschen Klasse platziert. Behebung: Verschieben Sie die Methode in die datenbesitzende Klasse oder erstellen Sie eine neue Klasse (Pure Fabrication), die sowohl die Daten als auch die Logik besitzt.

Überprüfen Sie bei der Code-Review: Wenn eine Methode 3+ Felder derselben Klasse als Parameter nimmt, ist das ein Zeichen dafür, dass die Methode eine Methode dieser Klasse sein sollte, nicht einer externen.

Übermäßige Nutzung von Pure Fabrication: Zu viele künstliche Klassen

Pure Fabrication ist ein mächtiges Muster, aber sein Übergebrauch führt zur „Klasseninflation“: Helper, Util, Manager, Provider, Processor, Handler, Coordinator, Orchestrator, Builder, Factory — jede zweite Klasse ist eine Pure Fabrication ohne reale Domänenentität. Konsequenz: Die Codebasis verliert den Bezug zur Domäne.

Laut SEI Software Architecture Report (2023) haben Projekte, in denen mehr als 40% der Klassen Pure Fabrication sind, eine um 29% höhere Einstiegshürde für neue Entwickler. Domänenklassen (User, Order, Product) sind für das Geschäft verständlich. Pure Fabrication-Klassen (UserManager, OrderProcessor) — nur für Entwickler. Gleichgewicht: Nicht mehr als 30% Pure Fabrication von der Gesamtzahl der Klassen.

Überprüfen Sie vor der Erstellung einer Pure Fabrication: Kann diese Verantwortung in einer bestehenden Domänenklasse (Information Expert) platziert werden? Wenn ja, erstellen Sie keine neue Klasse. Wenn nicht und Kopplung/Kohäsion leiden, ist Pure Fabrication gerechtfertigt.