Pattern G.R.A.S.P Fabrication pure
Problème initial
Où mettre certaines opérations, méthodes qui n’ont aucun rapport avec notre système et qui mettent en péril le faible couplage et la forte cohésion ?Solution associée
On crée une nouvelle classe qui s’occupe quasi exclusivement que de gérer cette méthode.Définition
Certaines opérations complexes requièrent un ensemble d'objets génériques qui n'ont aucun rapport avec le domaine et dont la responsabilité ne peut être assignée à des classes du domaine, afin d'éviter le fort couplage.La responsabilité doit être assignée à de nouvelles classes, fabriquées expressément pour effectuer l'opération.
Exemple
On cherche à enregistrer les instances de la classe Client dans une base de données pour qu’à chaque ajout de client dans le système il soit automatiquement ajouter dans les archives.On a la classe Client suivante :
En suivant les patterns vus jusqu’à présent et notamment le pattern Expert on se dit qu’il faut que ce soit la classe Client elle-même qui soit responsable de l’enregistrement d’un nouveau Client dans la base de données. On ajoute donc les éléments adéquates à la classe.
On a donc ajouté un nouvel attribut de type SGBD qui représente notre BD et qui est static (attribut souligné) pour être commun à toutes les instances de Client ainsi qu’une méthode insertionBD() qui s’occupe simplement d’ajouter le client dans la BD.
On peut donc penser que l’on a terminé mais si l’on étudie le couplage et la cohésion de cette « nouvelle » classe on remarque qu’il y a quelques soucis.
Tout d’abord le fait de lier la classe Client à une base de données, à une nouvelle entité, fait augmenter le couplage.
De plus l’enregistrement d’un élément dans une base de données avec un langage orienté objet oblige le développeur à prévoir et à écrire un certain nombre d’opération (connexion à la base, vérification de l’enregistrement, vérification de la synthaxe, vérification qu’il n’y ait pas de doublons,…) ce qui entraîne une baisse de la cohésion de la classe Client car il y a plus d’opérations liées à la BD que d’opérations liées à l’objet Client.
Il est donc nécessaire de créer une autre classe dont le rôle sera uniquement de gérer l’insertion dans la BD.
On obtient donc le diagramme suivant :
Le couplage n’est peut-être pas réduit mais la cohésion est préservée !
A retenir
Ce pattern est à appliquer si la/les méthodes qu’on souhaite ajouter dans une classe :- Engendre(nt) un trop grand nombre d’opération,
- Engendre(nt) une incohérence dans la classe
Remarque : Avec ce pattern l’ajout de nouvelles méthodes est plus simple car cela évite de devoir modifier toutes les instances d’une autre classe.