Grasp pattern

Les patterns GRASP sont des patrons crs par Craig Larman qui dcrivent des rgles pour affecter les responsabilits aux classes d'un programme orient objet pendant la conception, en liaison avec la mthode de conception BCE (Boundary Control Entity), en franais MVC (Modle Vue Contrleur). Il y a 9 patterns GRASP : Crateur, Expert, Faible couplage, Contrleur, Forte cohsion, Fabrication pure, Polymorphisme, Protection des variations, Indirection. Remarque : ces patterns ne sont qu'une aide pdagogique qui permet de structurer et de nommer des principes. Une fois que ces principes sont saisis, les termes spcifiques sont sans importance. Les patrons de conception GRASP sont les suivants :

1. Expert en information
Le principe de l'expert en information est d'assigner la responsabilit d'une requte la classe qui dtient les informations ncessaires. Il s'agit de crer la mthode l o les donnes se trouvent. Il s'agit d'appliquer le principe Celui qui sait le fait ou de mettre les services avec les attributs.

Exemple :
Facture

Facturation

Dans un logiciel de gestion de vente, nous avons les classes et attributs suivants :

Contient un ensemble de produit factur. Attribut : client, ProduitFactur Contient un lien vers la description d'un article. Attribut : quantit, Article Description d'un article. Attributs : nom, prix_unitaire (TTC), identifiant.

1 Grasp pattern - Mohamed Samine

Problme : quelle(s) classe(s) assigner la responsabilit de calculer le total de la facture ? La classe ProduitFactur connat l'article utilis et la quantit commande. On lui ajoute une mthode sousTotal() qui demandera le prix unitaire l'Article et le multipliera par la quantit.

La classe Facture connat la liste de tous les produits facturs. On lui ajoute une mthode
total() qui effectue la somme des sous-totaux demands aux diffrentes instances de la

classe ProduitFactur en appelant la mthode sousTotal().

Cet exemple illustre comment une responsabilit peut tre rpartie sur plusieurs classes. Chaque classe est responsable de la partie qui la concerne.

Cet exemple dmontre galement que ce patron de conception favorise l'encapsulation : Une classe n'a pas besoin de connatre la structure interne de la classe Facture pour calculer le montant total d.

2. Crateur
Le principe du crateur est d'assigner la responsabilit de la cration des instances d'une classe A. Cette responsabilit est assigne la classe B si au moins l'une des conditions suivantes est vraie :

B contient des instances de A, B est une agrgation d'instances de A, B utilise des instances de A de manire dtaille, B possde des informations pour crer des instances de A.

Exemples :Facturation
Dans un logiciel de gestion de vente, nous avons les classes et attributs suivants :

2 Grasp pattern - Mohamed Samine

Facture Contient un ensemble de produit factur. Attribut : client,

ProduitFactur Contient un lien vers la description d'un article. Attribut : quantit, Article Description d'un article. Attributs : nom, prix_unitaire (TTC), identifiant.

quelle(s) classe(s) assigner la responsabilit d'ajouter un nouveau produit factur (une nouvelle instance de la classeProduitFactur) ? La classe Facture contient des instances de ProduitFactur. Elle est donc responsable de leur cration.

3. Faible couplage
Le couplage mesure la dpendance entre des classes ou des modules. Le faible couplage favorise :

la faible dpendance entre les classes, la rduction de l'impact des changements dans une classe, la rutilisation des classes ou modules.

Pour affaiblir le couplage, il faut :

diminuer la quantit de paramtres passs entre les modules. viter d'utiliser des variables globales (par exemple, si une mauvaise valeur est assigne, dtecter la fonction/classe incorrecte est plus difficile), il vaut mieux passer les valeurs en paramtres.

3 Grasp pattern - Mohamed Samine

Exemples :Facturation
Dans un logiciel de gestion de vente, nous avons les classes suivantes : Facture Contient un ensemble de produit factur et est associe un mode de paiement, Paiement Dcrit un mode de paiement (espces, chque, carte bancaire, crdit, ...), Client Effectue les commandes.

On ajoute une mthode payer() la classe Client. On tudie le couplage dans les deux cas suivants : 1. La mthode payer() cre une instance de Paiement et l'assigne l'objet Facture. 2. La mthode payer() dlgue l'action la classe Facture qui cre une instance de Paiement et l'assigne. Le couplage est plus faible dans le deuxime cas car la mthode payer() de la classe Client n'a pas besoin de savoir qu'il existe une classe Paiement, c'est dire qu'elle ne dpend pas de l'existence ou non de cette classe.

4. Forte cohsion
La cohsion mesure la comprhensibilit des classes. Une classe doit avoir des responsabilits cohrentes, et ne doit pas avoir des responsabilits trop varies. Une classe ayant des responsabilits non cohrentes est difficile comprendre et maintenir. La forte cohsion favorise :

la comprhension de la classe, la maintenance de la classe, la rutilisation des classes ou modules.

Ce patron de conception peut tre utilis pour le faible couplage.

4 Grasp pattern - Mohamed Samine

5. Contrleur
Un contrleur est une classe qui traite les messages systmes. Certains messages systmes sont gnrs par des sources externes l'application en cours de conception. Il est conseill d'assigner cette responsabilit :

soit une classe reprsentant l'organisation globale ou le systme global (contrleur de faade), soit une classe reprsentant un acteur du domaine (contrleur de rle), soit une classe artificielle reprsentant un cas d'utilisation (contrleur de cas d'utilisation).

Dans la cas des interfaces graphiques, en suggrant la cration d'une classe contrleur spare, ce patron de conception encourage le faible couplage en rduisant les dpendances entre l'interface graphique et le modle.

Exemples :Bibliothque
Dans un logiciel de gestion de Bibliothque, la responsabilit de traiter le message "Supprimer tel livre" peut tre assign :

soit la classe Bibliothque (contrleur de faade), soit la classe Libraire (contrleur de rle), soit la classe Suppression (contrleur de cas d'utilisation).

6. Polymorphisme
Le polymorphisme est une proprit de la programmation objet o une classe peut dfinir un comportement par dfaut (une mthode de classe), voire ne dfinir que la signature de la mthode (classe abstraite). Ce comportement pouvant tre redfini par des sous-classes afin de le modifier pour certains types d'objets. Sans le polymorphisme, il serait ncessaire d'utiliser plusieurs tests (instructions if ou switch en gnral) dans la mthode afin de dfinir diffrents comportement en fonction du type d'objet. L'ajout d'un nouveau type oblige la modification de la mthode pour ajouter un test et un nouveau comportement.

5 Grasp pattern - Mohamed Samine

Dans le cas du polymorphisme, l'ajout d'un nouveau type d'objet implique uniquement la cration d'une nouvelle classe tendant la classe de base par un nouveau comportement. Le polymorphisme permet donc une meilleure extensibilit de l'application. Le but du patron polymorphisme est d'assigner la responsabilit du changement de comportement au type ( la classe) concern.

7. Fabrication pure
Certaines oprations complexes requiert un ensemble d'objets gnriques qui n'ont aucun rapport avec le domaine et dont la responsabilit ne peut tre assigne des classes du domaine, afin d'viter le fort couplage. La responsabilit doit tre assigne de nouvelles classes, fabriques expressment pour effectuer l'opration.

Exemples :Bibliothque
Dans un logiciel de gestion de Bibliothque, la responsabilit de sauvegarder les informations propos d'un livre dans une base de donnes ne doit pas tre assigne la classe Livre elle-mme, mais des classes spares, indpendantes (donc plus gnriques et rutilisables). Ces classes sont alors utilises par la classe Livre pour effectuer la sauvegarde.

8. Indirection
Afin d'viter le fort couplage entre deux classes, ou une dpendant une interface spcifique, il est recommand de crer une classe intermdiaire. Il faut cependant ne pas crer trop de classes intermdiaires afin d'viter de mauvaises performances (temps/mmoire).

6 Grasp pattern - Mohamed Samine

Exemples :Paiementenligne
La communication avec un serveur bancaire peut se faire grce un modem en utilisant des fonctions de l'API du systme d'exploitation. La cration d'une classe Modem pour appeler l'API permet d'viter l'appel celle-ci dans les classes communiquant par modem. L'application sera plus facilement porte pour un autre systme en ne changeant que la classe Modem.

9. Protection
Le but du patron de conception Protection est d'assigner les responsabilits afin que des variations dans des classes (instabilit) ne produisent aucun effet indsirable sur le reste du systme. Ce patron de conception est utilis en prvision d'volutions de l'application logicielle, afin d'viter que de nouvelles fonctionnalits ne viennent perturber l'existant. Pour mettre en uvre la protection contre les variations, on peut :

crer des mthodes pour accder aux attributs d'une classe, crer une interface pour grer de nouvelles classes en dfinissant les mthodes qui pourront tre appeles, crer des classes intermdiaires (voir le patron de conception indirection).

Il faut veiller ne pas trop anticiper les changements possibles afin d'viter de complexifier la structure de l'application en crant trop de classes intermdiaires ou d'interfaces.

Exemples :Bibliothque
Dans le pseudo-code suivant, l'obtention d'un livre particulier passe par l'utilisation de la classe Collection (classe que l'on ne connait pas, qui pourrait voluer, ou ne plus faire partie de l'application) : Collection c = bibliothque.getCollection(); Livre l = c.getLivre("Patrons de conception"); En appliquant le principe du patron de conception protection, la bibliothque est responsable de l'utilisation de la classe inconnue pour obtenir un livre particulier : Livre l = bibliothque.getLivre("Patrons de conception");

7 Grasp pattern - Mohamed Samine