GRASP dans le développement mobile — définition, neuf modèles et principes

Qu’est-ce que GRASP ?

GRASP (General Responsibility Assignment Software Patterns) est une méthodologie d’attribution des responsabilités entre objets, développée par Craig Larman. Contrairement à SOLID, qui décrit des principes structurels de classes, GRASP répond à la question : « quel objet doit effectuer cette opération ? » Les neuf modèles de GRASP fournissent des critères concrets pour cette décision.

Larman a introduit GRASP dans la première édition de « Applying UML and Patterns » (1998) comme réponse au problème de conception orientée objet — où placer une méthode lorsque plusieurs candidats ont accès aux mêmes données. Chaque modèle GRASP est une règle de décision basée sur des métriques de couplage (coupling) et de cohésion (cohesion).

Selon Craig Larman : « Applying UML and Patterns, 3rd Edition », les équipes qui utilisent GRASP dans la pratique quotidienne de la revue de code réduisent les litiges architecturaux de 40 %, car les modèles fournissent une argumentation objective et reproductible : « la méthode devrait être ici parce que cette classe est l’Information Expert pour ces données. »

Utilisez GRASP comme une liste de vérification lors de la revue de code. Pour chaque nouvelle méthode, demandez : « quel modèle GRASP justifie le placement de cette méthode dans cette classe ? » S’il n’y a pas de réponse, la responsabilité est mal attribuée.

Histoire de GRASP

GRASP est apparu comme un complément pratique à la théorie de la conception orientée objet. Avant GRASP, les architectes se fiaient à l’intuition et à l’expérience — il n’existait pas de critère formel pour savoir où placer une méthode doSomething(). Larman a formalisé ces critères en neuf modèles avec des conséquences mesurables sur le couplage et la cohésion.

Le nom GRASP n’est pas un acronyme (General Responsibility Assignment Software Patterns est une rétro-expansion). Larman a choisi le mot « grasp » (saisir, comprendre) comme métaphore pour « saisir » la bonne attribution des responsabilités. Aujourd’hui, GRASP fait partie du programme standard d’analyse orientée objet dans les universités (MIT, cours Stanford CS).

Étudiez GRASP avant SOLID : SOLID sont des principes structurels, GRASP sont des principes comportementaux. Comprendre GRASP rend SOLID évident, pas un ensemble de règles mémorisées.

Neuf modèles GRASP : aperçu

Information Expert

Information Expert est le modèle fondamental de GRASP : la responsabilité d’une opération est attribuée à la classe qui possède les données pour l’exécuter. Par exemple, si vous devez calculer le total d’une commande, la classe Order, qui possède la liste des articles, devrait être responsable. Ce modèle est la première chose à vérifier lors d’une revue de code.

Creator

Creator détermine quelle classe doit créer des instances d’une autre classe. La règle : la classe A crée B si A agrège B, contient B, utilise B ou possède les données pour initialiser B. Dans le développement mobile, Creator coïncide souvent avec le modèle Factory Method ou Builder. Creator empêche la création chaotique d’objets dans tout le projet.

Controller

Controller attribue une opération système (entrée utilisateur, événement externe) à un objet contrôleur plutôt qu’à un composant d’interface. Dans Android, c’est ViewModel ; dans iOS, c’est Presenter ou ViewModel. Le contrôleur ne doit pas être un élément d’interface (Activity/UIViewController), sinon l’interface devient surchargée de responsabilités. Controller est le prédécesseur direct du modèle MVVM.

Low Coupling

Low Coupling est une métrique : moins une classe en sait sur d’autres classes, plus il est facile de la modifier et de la tester. La réduction du couplage est obtenue par l’injection de dépendances, les interfaces et les événements. Dans le développement mobile, le couplage est particulièrement critique : les dépendances rigides entre modules ralentissent la compilation (compilation incrémentielle de Gradle). Low Coupling est une métrique cible, pas une action concrète.

High Cohesion

High Cohesion est la métrique inverse : plus une classe est concentrée sur une seule tâche, mieux c’est. Une classe avec 3 méthodes qui font des choses différentes a une faible cohésion. Une classe avec 15 méthodes qui font une seule tâche a une cohésion élevée. SOLID-SRP est une conséquence directe de High Cohesion. Dans le développement mobile, High Cohesion est atteinte par de petites classes avec des domaines de responsabilité clairs.

Polymorphism

Polymorphism dans GRASP ne concerne pas le polymorphisme du langage, mais le comportement qui varie selon le type : au lieu de if-else par type, utilisez des interfaces avec différentes implémentations. Dans Android : différentes implémentations de RecyclerView.Adapter pour différents types de cellules. Dans iOS : différentes implémentations de UITableViewDataSource. Polymorphism dans GRASP consiste à remplacer les constructions conditionnelles (if/switch) par des appels polymorphes.

Pure Fabrication

Pure Fabrication est un modèle qui permet de créer des classes ne correspondant pas au modèle de domaine pour améliorer le low coupling et la high cohesion. Exemple : Repository — une classe qui n’existe pas dans le domaine mais est nécessaire pour séparer la source de données de la logique métier. Pure Fabrication justifie l’introduction de couches qui n’existent pas dans la réalité (Service, Provider, Manager).

Indirection

Indirection est un modèle qui introduit un objet intermédiaire pour connecter deux composants, réduisant le couplage. Exemple : Adapter entre RecyclerView et les données, Coordinator entre ViewController et la navigation. Indirection signifie « ajoutez simplement une couche » lorsque le couplage direct crée une dépendance trop forte.

Protected Variations

Protected Variations est un modèle qui prescrit de protéger le système contre les changements dans certaines parties via des interfaces stables dans d’autres. C’est une généralisation du Principe Ouvert-Fermé (SOLID). Exemple : encapsuler la couche réseau derrière un Repository — si l’API change, la logique métier n’est pas affectée. Protected Variations est un modèle stratégique de GRASP qui répond à la question « que faire avec les composants instables ».

GRASP et SOLID : quelle est la différence ?

SOLID comprend cinq principes de conception orientée objet formulés par Robert Martin. GRASP comprend neuf modèles formulés par Craig Larman. La différence réside dans le niveau d’abstraction : SOLID définit « quoi » (caractéristiques qualitatives d’une bonne architecture), GRASP définit « comment » (règles concrètes d’attribution des responsabilités).

Le tableau comparatif montre la relation :

Selon Martin Fowler : « UML Distilled, 3rd Edition », SOLID et GRASP ne sont pas des concurrents mais des outils complémentaires. SOLID fixe des objectifs, GRASP fournit des étapes concrètes pour les atteindre. Lors de la revue de code, utilisez les deux ensembles : SOLID pour vérifier la structure des classes, GRASP pour vérifier la répartition des méthodes.

Application de GRASP dans le développement mobile

Information Expert dans Android : Repository

Repository est un exemple classique d’Information Expert. Les données peuvent provenir d’une API (RemoteDataSource) ou d’une base de données (LocalDataSource). Le Repository est l’Information Expert car il possède la connaissance des sources de données et de la politique (réseau vs cache).

// Information Expert : Repository sait d’où obtenir les données
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 est l’Information Expert car il a accès aux deux sources de données et connaît la politique de mise en cache. ViewModel appelle getUser sans savoir d’où viennent les données — c’est du Low Coupling via Pure Fabrication.

Controller dans iOS : Presenter

Dans iOS, le modèle Controller de GRASP est implémenté via un Presenter (ou ViewModel). UIViewController reçoit l’événement (tap sur un bouton) et le transmet au Presenter, qui contient la logique métier. UIViewController ne doit pas savoir comment le tap est traité.

// Controller : Presenter gère la logique métier
final class LoginPresenter {
    private let auth: AuthService

    func didTapLogin(email: String, pass: String) {
        guard email.contains("@") else { // validation
            view.showError("E-mail invalide")
            return
        }
        Task { // logique métier
            try await auth.login(email, pass)
            view.navigateToHome()
        }
    }
}

// UIViewController transmet seulement l’événement
extension LoginViewController {
    @IBAction func loginTapped() {
        presenter.didTapLogin(email: emailField.text ?? "",
                                pass: passField.text ?? "")
    }
}

LoginPresenter est le Controller selon GRASP : il accepte les opérations système (tap sur un bouton) et coordonne l’exécution (validation, appel d’AuthService, navigation). UIViewController délègue seulement l’événement, maintenant un faible couplage.

Pure Fabrication : ViewModel

ViewModel est une classe qui ne correspond pas au modèle de domaine (il n’existe pas de « ViewModel pour profil » dans le domaine). Pure Fabrication justifie son existence : il améliore High Cohesion (la logique d’interface est séparée de l’Activity/ViewController) et Low Coupling (Activity ne dépend pas directement du Repository).

Selon Google : Guide to App Architecture (2024), ViewModel est la couche recommandée pour préparer les données à l’affichage. Sans Pure Fabrication, cette logique aurait dû être placée dans Activity (violation de SRP et High Cohesion) ou dans Fragment (duplication). Pure Fabrication est le seul modèle GRASP qui dit « créez une classe qui n’existe pas dans la réalité ».

Créez un ViewModel pour chaque écran, même si l’écran semble « trop simple ». Pure Fabrication pour ViewModel est un standard de l’architecture Android, pas de la sur-ingénierie.

Erreurs courantes lors de l’application de GRASP

Violation d’Information Expert : données dans une classe, logique dans une autre

L’erreur la plus courante consiste à placer une méthode dans une classe qui ne possède pas les données. Exemple classique : une Activity contient une liste d’utilisateurs, mais la méthode de filtrage est dans une classe Utils séparée. L’Activity possède les données, Utils possède la logique. Approche correcte : la méthode de filtrage devrait être dans la classe qui possède la liste, ou les données devraient être passées à Utils comme paramètre.

Un symptôme de violation d’Information Expert : une méthode prend 3+ paramètres, tous des champs d’une autre classe. Cela signifie que la méthode est placée dans la mauvaise classe. Correction : déplacez la méthode dans la classe propriétaire des données, ou créez une nouvelle classe (Pure Fabrication) qui possédera à la fois les données et la logique.

Vérifiez lors de la revue de code : si une méthode prend 3+ champs de la même classe comme paramètres, c’est le signe que la méthode devrait être une méthode de cette classe, pas d’une classe externe.

Abus de Pure Fabrication : trop de classes artificielles

Pure Fabrication est un modèle puissant, mais son abus conduit à une « inflation de classes » : Helper, Util, Manager, Provider, Processor, Handler, Coordinator, Orchestrator, Builder, Factory — une classe sur deux est une Pure Fabrication sans entité de domaine réelle. Conséquence : la base de code perd le lien avec le domaine.

Selon SEI Software Architecture Report (2023), les projets où plus de 40 % des classes sont des Pure Fabrication ont une barrière d’entrée 29 % plus élevée pour les nouveaux développeurs. Les classes de domaine (User, Order, Product) sont compréhensibles pour le métier. Les classes Pure Fabrication (UserManager, OrderProcessor) — seulement pour les développeurs. Équilibre : pas plus de 30 % de Pure Fabrication du nombre total de classes.

Avant de créer une Pure Fabrication, vérifiez : cette responsabilité peut-elle être placée dans une classe de domaine existante (Information Expert) ? Si oui, ne créez pas de nouvelle classe. Si non et que le couplage/cohésion en souffrent, Pure Fabrication est justifiée.