GRASP in Mobile Development — What It Is, Nine Patterns and Principles

What Is GRASP?

GRASP (General Responsibility Assignment Software Patterns) is a methodology for assigning responsibility between objects, developed by Craig Larman. Unlike SOLID, which describes structural principles of classes, GRASP answers the question: “which object should perform this operation?” The nine patterns of GRASP provide specific criteria for making this decision.

Larman introduced GRASP in the first edition of “Applying UML and Patterns” (1998) as an answer to the object-oriented design problem — where to place a method when multiple candidates have access to the same data. Each GRASP pattern is a decision-making rule based on metrics of coupling and cohesion.

According to Craig Larman: “Applying UML and Patterns, 3rd Edition”, teams using GRASP in daily code review practice reduce architecture disputes by 40% because the patterns provide objective, reproducible reasoning: “the method should be here because this class is the Information Expert for this data.”

Use GRASP as a checklist during code review. For each new method, ask: “which GRASP pattern justifies placing this method in this class?” If there’s no answer, the responsibility is assigned incorrectly.

History of GRASP

GRASP emerged as a practical complement to object-oriented design theory. Before GRASP, architects relied on intuition and experience — there was no formal criterion for where to place a doSomething() method. Larman formalized these criteria into nine patterns with measurable consequences for coupling and cohesion.

The name GRASP is not an acronym (General Responsibility Assignment Software Patterns is a backronym). Larman chose the word “grasp” as a metaphor for grasping the correct assignment of responsibility. Today, GRASP is part of the standard object-oriented analysis curriculum at universities (MIT, Stanford CS courses).

Study GRASP before SOLID: SOLID provides structural principles, GRASP provides behavioral ones. Understanding GRASP makes SOLID obvious rather than a set of memorized rules.

Nine GRASP Patterns: Overview

Information Expert

Information Expert is the fundamental GRASP pattern: responsibility for an operation is assigned to the class that has the data to perform it. For example, if you need to calculate an order total, the Order class, which owns the list of items, should be responsible. This pattern is the first thing to check during code review.

Creator

Creator determines which class should create instances of another class. The rule: class A creates B if A aggregates B, contains B, uses B, or has the data to initialize B. In mobile development, Creator often aligns with the Factory Method or Builder pattern. Creator prevents chaotic object creation across the project.

Controller

Controller assigns a system operation (user input, external event) to a controller object rather than to a UI component. In Android, this is ViewModel; in iOS, it is Presenter or ViewModel. The controller should not be a UI element (Activity/UIViewController), otherwise the UI becomes overloaded with responsibility. Controller is a direct predecessor of the MVVM pattern.

Low Coupling

Low Coupling is a metric: the less a class knows about other classes, the easier it is to modify and test. Reducing coupling is achieved through dependency injection, interfaces, and events. In mobile development, coupling is especially critical: tight module dependencies slow down compilation (Gradle incremental build). Low Coupling is a target metric, not a specific action.

High Cohesion

High Cohesion is the inverse metric: the more focused a class is on a single task, the better. A class with 3 methods doing different things has low cohesion. A class with 15 methods doing one task has high cohesion. SOLID-SRP is a direct consequence of High Cohesion. In mobile development, High Cohesion is achieved through small classes with clear areas of responsibility.

Polymorphism

Polymorphism in GRASP is not about language polymorphism, but about behavior that varies by type: instead of if-else by type, use interfaces with different implementations. In Android: different RecyclerView.Adapter implementations for different cell types. In iOS: different UITableViewDataSource implementations. Polymorphism in GRASP is about replacing conditional constructs (if/switch) with polymorphic calls.

Pure Fabrication

Pure Fabrication is a pattern that allows creating classes that do not correspond to the domain model to improve low coupling and high cohesion. Example: Repository — a class that does not exist in the domain but is needed to separate the data source from business logic. Pure Fabrication justifies introducing layers that do not exist in reality (Service, Provider, Manager).

Indirection

Indirection is a pattern that introduces an intermediate object to connect two components, reducing coupling. Example: Adapter between RecyclerView and data, Coordinator between ViewController and navigation. Indirection means “just add a layer” when direct coupling creates too tight a dependency.

Protected Variations

Protected Variations is a pattern that prescribes protecting the system from changes in some parts through stable interfaces in others. This is a generalization of the Open-Closed Principle (SOLID). Example: encapsulating the network layer behind a Repository — if the API changes, business logic is not affected. Protected Variations is a strategic GRASP pattern that answers the question “what to do with unstable components.”

GRASP and SOLID: What’s the Difference?

SOLID consists of five object-oriented design principles formulated by Robert Martin. GRASP consists of nine patterns formulated by Craig Larman. The difference lies in the level of abstraction: SOLID defines what (qualitative characteristics of good architecture), GRASP defines how (specific rules for responsibility assignment).

The comparison table demonstrates the relationship:

According to Martin Fowler: “UML Distilled, 3rd Edition”, SOLID and GRASP are not competitors but complementary tools. SOLID sets goals, GRASP provides specific steps to achieve them. During code review, use both sets: SOLID for checking class structure, GRASP for checking method distribution.

Applying GRASP in Mobile Development

Information Expert in Android: Repository

Repository is a classic example of Information Expert. Data can come from an API (RemoteDataSource) or from a database (LocalDataSource). The Repository is the Information Expert because it owns knowledge about data sources and policy (network vs cache).

// Information Expert: Repository knows where to get data
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 is the Information Expert because it has access to both data sources and knows the caching policy. ViewModel calls getUser without knowing where the data came from — this is Low Coupling through Pure Fabrication.

Controller in iOS: Presenter

In iOS, the Controller GRASP pattern is implemented through a Presenter (or ViewModel). UIViewController receives the event (button tap) and passes it to the Presenter, which contains the business logic. UIViewController should not know how the tap is handled.

// Controller: Presenter handles business logic
final class LoginPresenter {
    private let auth: AuthService

    func didTapLogin(email: String, pass: String) {
        guard email.contains("@") else { // validation
            view.showError("Invalid email")
            return
        }
        Task { // business logic
            try await auth.login(email, pass)
            view.navigateToHome()
        }
    }
}

// UIViewController only passes the event
extension LoginViewController {
    @IBAction func loginTapped() {
        presenter.didTapLogin(email: emailField.text ?? "",
                                pass: passField.text ?? "")
    }
}

LoginPresenter is the Controller per GRASP: it accepts system operations (button tap) and coordinates execution (validation, calling AuthService, navigation). UIViewController only delegates the event, maintaining Low Coupling.

Pure Fabrication: ViewModel

ViewModel is a class that does not correspond to the domain model (there is no “ViewModel for profile” in the domain). Pure Fabrication justifies its existence: it improves High Cohesion (UI logic is separated from Activity/ViewController) and Low Coupling (Activity does not directly depend on Repository).

According to Google: Guide to App Architecture (2024), ViewModel is the recommended layer for preparing data for display. Without Pure Fabrication, this logic would have to be placed in Activity (violating SRP and High Cohesion) or in Fragment (duplication). Pure Fabrication is the only GRASP pattern that says “create a class that does not exist in reality.”

Create a ViewModel for every screen, even if the screen seems “too simple.” Pure Fabrication for ViewModel is a standard of Android architecture, not overengineering.

Common Mistakes When Applying GRASP

Violating Information Expert: Data in One Class, Logic in Another

The most common mistake is placing a method in a class that does not own the data. Classic example: an Activity holds a list of users, but the filtering method is in a separate Utils class. The Activity owns the data, Utils owns the logic. Correct approach: the filtering method should be in the class that owns the list, or the data should be passed to Utils as a parameter.

A symptom of violating Information Expert: a method takes 3+ parameters, all of which are fields of another class. This means the method is placed in the wrong class. Fix: move the method to the data-owning class, or create a new class (Pure Fabrication) that will own both the data and the logic.

Check during code review: if a method takes 3+ fields of the same class as parameters, it’s a sign that the method should be a method of that class, not an external one.

Overusing Pure Fabrication: Too Many Artificial Classes

Pure Fabrication is a powerful pattern, but overusing it leads to “class inflation”: Helper, Util, Manager, Provider, Processor, Handler, Coordinator, Orchestrator, Builder, Factory — every second class is a Pure Fabrication without a real domain entity. Consequence: the codebase loses connection with the domain.

According to SEI Software Architecture Report (2023), projects where more than 40% of classes are Pure Fabrication have a 29% higher onboarding barrier for new developers. Domain classes (User, Order, Product) are understandable to the business. Pure Fabrication classes (UserManager, OrderProcessor) are only understandable to developers. Balance: no more than 30% Pure Fabrication of the total number of classes.

Before creating a Pure Fabrication, check: can this responsibility be placed in an existing domain class (Information Expert)? If yes, don’t create a new class. If not and coupling/cohesion suffer, Pure Fabrication is justified.