Pattern G.R.A.S.P Expert (en informations)

Problème initial

Quel est le principe général d’affectation des responsabilités aux objets ?

Solution associée

Affecter la responsabilité à l’expert en information c’est à dire la classe qui possède les informations nécessaires pour s’acquitter de la responsabilité.

Définition

L'objectif de ce pattern est d'affecter au mieux une responsabilité à une classe. Afin de réaliser ces responsabilités, cette classe doit disposer des informations nécessaires.

Lors de l'établissement du modèle de conception (modèle du domaine), il est très fréquent d'obtenir des centaines de classes logicielles, et l'étude approfondie des cas d'utilisation engendre l'extraction de centaines de responsabilités. En général, on impute la réflexion sur l'attribution des responsabilités dès la conception des diagrammes d'interaction entre les objets. C'est à ce moment que l'on définit quelle classe a quelle(s) responsabilité(s), ce qui détermine sans aucun doute une bonne ou une mauvaise conception. En effet, si les responsabilités sont mal réparties, les classes vont être difficilement maintenables, plus dure à comprendre, et avec une réutilisation des composants peu flexible.

Ainsi, comme d'autres pattern GRASP, le modèle Expert est un pattern relativement intuitif qui, en général, est respecté par le bon sens du concepteur. Il s'agit tout simplement d'affecter à une classe les responsabilités correspondants aux informations dont elle dispose intrinsèquement (qu'elle possède) ou non (objets de collaborations).

Exemple

Prenons un exemple très simple.

Soit le diagramme de classe suivant :



On souhaite ajouter la méthode getPrix() qui retourne le prix d’un Produit.
La question à se poser est : Quelle classe possède l’information que je veux ? Ici c’est clairement la classe Produit qui possède l’information du prix d’un Produit et donc c’est dans cette classe que l’on doit ajouter la méthode getPrix().
On obtient donc le nouveau diagramme suivant :



Maintenant on souhaite ajouter la méthode getPrix(int idProduit) qui retourne le prix d’un produit dont l’idProduit est passé en paramètre.
On se pose la même question : Quelle classe possède l’information que je veux ?

Ici deux classes pourraient posséder cette information : les classes Panier et Stock car toutes les deux possèdent, implicitement avec la relation, une liste de Produits.
Mais alors laquelle choisir ?
C’est à ce moment que dans la conception il faut se poser les bonnes questions et surtout comprendre à quoi sert chaque classe.

• La classe Stock possède la liste de l’ensemble des Produits disponibles
• La classe Panier possède la liste de l’ensemble des Produits choisis par un Client

Ainsi ici tout dépend de ce que l’on veut : - Si l’on veut que la méthode retourne un Produit choisie par un Client dans son Panier alors on placera la méthode dans la classe Panier - Par contre si l’on veut que la méthode retourne un Produit disponible et qui n’est pas forcément dans le Panier d’un Client alors on placera la méthode dans la classe Stock

C’est un choix d’implémentation mais cela met en relief le fait que la conception de diagrammes n’est pas toujours simple et qu’il faut en permanence se poser des questions

A retenir

Pour appliquer ce pattern il faut se poser les questions suivantes :

• Quelle information je veux retourner ou consulter avec la méthode que je cherche à placer ?
• Quelles classes possèdent cette information ?
• Au final quelle classe doit posséder cette information étant donné mes exigences et mes choix d’implémentation ?