Les principes GRASP

Depuis deux semaines, tu prends la même décision à chaque flèche que tu traces : à qui confier ce travail ? Tu la prends déjà avec la bonne question — mais sans le nom. Ce module donne les neuf noms, et c'est exactement ce que l'examen réclame : non pas décider juste, mais savoir dire pourquoi.

La question que chaque flèche posait

Reprends n'importe quel diagramme du module Les diagrammes d'interaction. Chaque flèche que tu y as tracée est une décision : tu as choisi qui recevrait ce travail. Le contrôleur aurait pu calculer lui-même ; tu as préféré déléguer au livre. Rien, dans la notation, ne t'y obligeait.

Cette décision est la plus lourde de toute la conception orientée objet, parce qu'elle se répète des centaines de fois et qu'aucune ne s'annule. GRASP — General Responsibility Assignment Software Patterns — est la liste des neuf raisons acceptables de trancher. Neuf patrons, neuf questions.

Deux précisions avant d'entrer dans le détail, et les deux tombent en examen.

Ce ne sont pas les patrons de conception. Ceux-là — Fabrique, Singleton, Observateur, Stratégie — arrivent en semaine 10, ils viennent du « Gang of Four » et ce sont des solutions nommées, avec un diagramme de classes chacune. Les GRASP sont d'un cran au-dessus : des principes d'attribution, sans structure imposée. On ne « dessine pas un Expert », on justifie une décision par Expert.

Ils s'appliquent au moment du diagramme d'interaction, pas après. C'est là qu'on choisit un destinataire pour chaque message ; le diagramme de classes ne fait qu'enregistrer le résultat. Un GRASP invoqué après coup ne sert qu'à défendre ce qu'on a déjà écrit — ce qui est exactement l'exercice de l'examen, mais pas la façon de concevoir.

Expert — celui que tu appliques déjà

L'énoncé : confier une responsabilité à la classe qui détient l'information nécessaire pour l'assumer. C'est le plus fondamental des neuf, et de loin le plus souvent invoqué en correction.

Tu l'as appliqué sans le savoir la semaine dernière. L'exercice du module Les diagrammes d'interaction demandait pourquoi un contrôleur qui lit le montant dû d'un lecteur, le décompte dans son coin et réécrit le résultat était mal conçu. La réponse — le montant dû appartient au lecteur, donc c'est lui qui doit savoir encaisser — est Expert, mot pour mot. Il ne te manquait que le nom, et c'est le nom que le correcteur cherche.

Pourquoi ça marche : parce que l'alternative consiste à promener la donnée. Chaque information qu'une classe va chercher ailleurs pour calculer elle-même coûte un message de plus sur le diagramme et une dépendance de plus dans le code. Expert n'est donc pas une préférence esthétique : c'est le patron qui réduit mécaniquement les deux choses qu'on cherche à réduire.

<responsabilité> → <classe>
   par <PATRON>, parce que <raison>

   calculerSousTotal() → LigneCommande
      par EXPERT, parce qu'elle detient la
      quantite et atteint le prix du plat

   creerEmprunt() → Lecteur
      par CREATEUR, parce qu'il enregistre
      ses emprunts

La raison nomme un FAIT du diagramme : une
donnee possedee, une agregation, un
evenement recu. Jamais « c'est plus propre ».

class Emprunt {
   private Date datePret;
   private Date dateRetourPrevue;
   private Livre livre;
}
class Lecteur {
   private List<Emprunt> emprunts;
}

Créateur — qui a le droit d'instancier

Quand tu as tracé le message «create» vers :Emprunt, la semaine dernière, tu as choisi son émetteur. Créateur dit lequel choisir. L'énoncé : confier à B la création d'un A si l'une de ces conditions est vraie — et il suffit d'une seule :

• B contient ou agrège A — une Commande contient ses LigneCommande ;
• B enregistre A — un RegistreEmprunts tient la liste des emprunts ;
• B utilise A étroitement ;
• B possède les données d'initialisation de A — c'est la condition la plus utile en pratique, parce qu'elle se vérifie en regardant le constructeur.

La première est la plus forte : quand une composition existe, la question ne se pose même pas. Le module Le modèle du domaine t'a fait tracer des losanges pleins pour dire « l'un ne vit pas sans l'autre » ; Créateur en tire la conséquence directe — celui qui contient est celui qui fabrique. Une ligne de commande n'existe pas hors de sa commande, donc rien d'autre que la commande n'a de raison de l'instancier.

Et quand plusieurs conditions désignent des classes différentes ? Larman tranche en faveur de celle qui agrège ou contient : c'est celle dont le lien durera. Les données d'initialisation, elles, ne font que passer.

class Lecteur {
   private List<Emprunt> emprunts;   // il agrege
}
class RegistreEmprunts {
   private List<Emprunt> tous;       // il enregistre
}
class ControleurEmprunt {
   // recoit confirmerEmprunt(lecteur, livre)
}

Contrôleur — ce que GRASP ajoute

Celui-ci, tu le connais : deux modules l'ont déjà installé, du stéréotype «controller» jusqu'au premier message de chaque diagramme d'interaction. L'énoncé : confier la réception d'un événement système à une classe qui représente soit le système entier, soit un cas d'utilisation. Ce que GRASP ajoute tient en deux choses.

Premièrement, les deux variantes ont des noms et un critère de choix. Le contrôleur de façade est une classe unique pour tout le système — Bibliotheque, SystemeDeCaisse : acceptable tant que les cas d'utilisation se comptent sur une main. Le contrôleur de cas d'utilisation en donne un par scénario — ControleurEmprunt, ControleurRetour —, et c'est le choix par défaut dès qu'un système grossit. Le critère n'est pas le goût : c'est le nombre d'opérations système que la classe finirait par porter.

Deuxièmement, le défaut a un nom officiel : le contrôleur surchargé (bloated controller). Tu l'as déjà croisé deux fois sans qu'on te le nomme, dans le quiz des stéréotypes et dans le piège du diagramme en peigne. Trois symptômes le révèlent, et le troisième est le plus révélateur : la classe reçoit des opérations venues de cas d'utilisation sans rapport ; elle exécute au lieu de déléguer ; et elle garde des attributs qui dupliquent ce que les entités savent déjà.

Couplage et cohésion, la paire qu'on confond

Ces deux-là vont ensemble dans ce module parce que c'est ensemble qu'on les confond. Ils diffèrent d'ailleurs des autres patrons par leur nature : les sept autres désignent une classe, ceux-ci jugent le résultat. Ils ne répondent pas à « qui fait quoi » mais à « est-ce que ce que je viens d'écrire tient debout ».

Faible couplage : minimiser les dépendances entre classes. Une classe est couplée à toutes celles qu'elle doit connaître pour fonctionner — celles dont elle garde une référence, celles qu'elle reçoit en paramètre, celles dont elle appelle une méthode. Plus elle en connaît, plus un changement ailleurs peut la casser.

Forte cohésion : une classe, un objectif. Une classe est cohésive quand tout ce qu'elle contient sert la même chose. Quand elle porte la logique métier, l'accès à la base, l'envoi de courriels et la génération de PDF, elle n'est plus une classe mais un dossier.

class CalculateurTaxe {
   private Commande commande;
   private LigneCommande ligne;
   private Plat plat;
   private Client client;
   private Province province;

   double calculer() { /* ... */ }
}

Polymorphisme, et là où il s'arrête

Le mécanisme, tu le connais depuis le cours de programmation : quand un comportement dépend du type de l'objet, chaque sous-classe redéfinit la méthode, et l'appelant ne teste plus rien. Ce que GRASP y ajoute est un point de vue : ce n'est pas une astuce de langage, c'est une attribution de responsabilité. Au lieu de confier la décision à un aiguilleur central qui connaît tous les cas, on la confie à chaque type, qui ne connaît que le sien.

D'où l'énoncé, et son bénéfice : ajouter un cas devient ajouter une classe, sans rouvrir le code existant. Un if/else sur un type, lui, se rouvre à chaque nouveau cas — et on oublie toujours l'un des endroits où il avait été recopié.

Le vrai sujet de cette section est ailleurs, parce que c'est là qu'on se trompe : tous les if ne sont pas des polymorphismes qui s'ignorent. Le patron vise une variation de type, et le test tient en une phrase :

double fraisLivraison(Commande c) {
   if (c.total() >= 50) return 0.0;
   else                 return 7.95;
}

Reste la question qui revient toujours en examen : polymorphisme, ou protégé des variations ? Les deux, et il faut le dire. Protégé des variations est l'intention — isoler ce qu'on sait devoir changer derrière une interface stable ; le polymorphisme est le mécanisme qui la réalise le plus souvent. Une copie qui nomme les deux et explique lequel sert lequel vaut mieux qu'une copie qui parie sur l'un des deux. On y revient dans la section « Indirection et protégé des variations ».

Et garde ceci pour la semaine 10 : quand le cours arrivera aux patrons du « Gang of Four », tu retrouveras exactement cette structure sous le nom de Stratégie. Le polymorphisme GRASP en est le principe ; Stratégie en est la forme nommée, avec son diagramme de classes.

Fabrication pure — inventer une classe

Les six patrons précédents désignent tous une classe qui existe déjà. Celui-ci traite le cas où aucune ne convient. L'énoncé : quand aucune classe du domaine n'est un hôte naturel pour une responsabilité, en inventer une, sans équivalent dans le monde réel, dédiée à cette tâche.

Le nom dit exactement ce qu'il faut comprendre : fabrication, parce qu'on la fabrique ; pure, parce qu'elle ne représente rien — le client ne la reconnaîtrait pas, aucun modèle du domaine ne la contient.

Le cas d'école est la persistance. Il faut ranger un Emprunt dans une base SQL. Expert désignerait Emprunt, puisque c'est lui qui détient les données — et ce serait une faute : une entité du métier qui sait parler SQL perd sa cohésion, devient impossible à tester sans base, et le module Le diagramme de classes & l'architecture logique a déjà montré que cet appel-là traverse une couche interdite. On invente donc EmpruntDAO, que tu as croisé sans savoir d'où il venait : c'est une fabrication pure, et c'est la plus fréquente de toutes.

Remarque au passage ce que ce patron vient de faire : il a arbitré contre Expert. C'est normal et c'est examinable — les GRASP ne s'appliquent pas en file indienne, ils se contredisent parfois, et une bonne copie dit lequel l'emporte et pourquoi. Ici, la cohésion des entités pèse plus lourd que la proximité des données.

La persistance n'est pas son seul emploi, et connaître les autres évite de croire que « fabrication pure » est un synonyme de « DAO ». Trois familles reviennent : la traduction d'un format vers un autre — un ConvertisseurJSON, un LecteurCSV ; la communication avec l'extérieur — une passerelle de paiement, un service de courriel ; et l'algorithme lourd qui ne tient dans aucune entité sans l'alourdir — un PlanificateurHoraire, un CalculateurItineraire. Toutes ont la même signature : une responsabilité que le métier n'a jamais eu à nommer.

D'où le critère qui autorise l'invention, et il est plus utile que la liste : une fabrication pure légitime est celle dont on peut dire ce qu'elle fait sans jamais nommer une classe du domaine. « Elle traduit un objet en JSON », « elle range des entités dans une base » — ces phrases tiennent seules, et c'est pourquoi ces classes sont réutilisables ailleurs. Une classe dont la description commence par « elle gère les emprunts » échoue au test : elle a besoin du domaine pour se définir, donc sa place était dans le domaine.

Ne le confonds pas avec Créateur, ce qui est l'erreur de vocabulaire la plus courante du chapitre : Créateur choisit qui instancie une classe qui existe ; Fabrication pure décide d'en inventer une qui n'existe pas. L'un désigne, l'autre crée.

Indirection et protégé des variations

Les deux derniers vont ensemble parce qu'ils décrivent souvent la même ligne de code, vue sous deux angles. Les séparer proprement est un point de barème.

Indirection : pour que deux classes cessent de se connaître, intercaler un intermédiaire. L'application doit envoyer des courriels et une bibliothèque externe sait le faire. Si dix classes l'appellent directement, dix classes dépendent d'un produit qu'on ne contrôle pas. On intercale ServiceCourriel : les dix parlent à lui, lui seul parle à la bibliothèque. En changer devient une modification à un seul endroit.

Protégé des variations : repérer ce qu'on sait devoir changer, et poser une interface stable autour. On sait que les moyens de paiement vont se multiplier. On définit donc Paiement avec payer(montant), et le reste du système ne parle qu'à cette interface ; ajouter un moyen n'oblige à rouvrir personne.

Ce qui les distingue : l'indirection est un GESTE, protégé des variations est une INTENTION. Intercaler une classe est un geste qu'on peut faire pour bien d'autres raisons — un cache, un journal des appels, une conversion de format —, et ce n'est alors pas du protégé des variations. Inversement, protéger des variations n'exige pas toujours d'intercaler quoi que ce soit : une hiérarchie polymorphe suffit souvent, et c'est le lien avec la section précédente.

Une façon rapide de trancher sur une copie : cherche dans l'énoncé s'il annonce un changement à venir. « Le client voudra d'autres moyens de paiement », « on changera peut-être de fournisseur » — dès qu'un futur est nommé, c'est protégé des variations, et l'indirection ou le polymorphisme n'en sont que la réalisation.

(A) Une classe Voiture porte 30 méthodes :
    consommation, sauvegarde en base,
    affichage du tableau de bord, calcul
    d'assurance.

(B) Une classe Compte calcule son solde à
    partir de ses propres transactions.

(C) Une classe Cache s'intercale entre
    l'application et une base lente.

(D) Une classe FactureDAO est créée pour
    stocker des Factures : aucune classe
    métier ne voulait de cette tâche.

(E) Une Commande instancie ses LigneCommande.

Citer le bon patron, sur une copie

Les questions d'examen sur GRASP prennent trois formes, et une seule compétence les couvre toutes : identifiez le patron applicable, justifiez le choix de cette classe, corrigez cette conception en citant le patron violé. Aucune ne demande de réciter un énoncé. Toutes demandent de nommer, puis de motiver.

La méthode tient en trois gestes, et elle vaut aussi bien pour analyser que pour corriger.

1. Nomme la responsabilité, avec un verbe. « Calculer l'amende », « créer l'emprunt », « stocker les factures ». Tant que la responsabilité n'est pas nommée, il n'y a rien à attribuer — et beaucoup de copies échouent là, en parlant des classes avant de parler du travail.
2. Demande qui détient l'information. Commence toujours par Expert : c'est la bonne réponse dans la majorité des cas, et les autres patrons se justifient le plus souvent comme des exceptions à Expert — la fabrication pure quand l'expert naturel y perdrait sa cohésion, le contrôleur quand l'événement vient de l'extérieur.
3. Écris la raison en nommant un fait du diagramme. Une donnée possédée, une composition, un événement reçu. « Parce que c'est plus propre » ne vaut rien ; « parce qu'elle détient la quantité » vaut le point.

class ControleurCommande {

   double calculerTotal(Commande c) {
      double total = 0;
      for (LigneCommande l : c.getLignes()) {
         Plat p = l.getPlat();
         total += p.getPrix() * l.getQuantite();
      }
      return total;
   }
}