Patrons de conception/Expert en information

Un livre de Wikilivres.
Sauter à la navigation Sauter à la recherche
Patrons de conception
Patrons de conception
Sommaire
Patron de conception
Catégorie: GRASP
Nom français : Expert en information
Nom anglais : Information expert
Assigner la requête d'information à la classe détenant l'information


Le principe de l'expert en information est d'assigner la responsabilité d'une requête à la classe qui détient les informations nécessaires. Il s'agit de créer la méthode là où les données se trouvent.

Il s'agit d'appliquer le principe « Celui qui sait le fait » ou de mettre les services avec les attributs.

Exemples[modifier | modifier le wikicode]

Bibliothèque[modifier | modifier le wikicode]

Dans un logiciel de gestion de bibliothèque, nous avons créé les classes Bibliothèque et Catalogue. Nous voulons ajouter une méthode retournant le livre en fonction de son numéro. À quelle classe assigner cette responsabilité ?

La classe susceptible de détenir les informations nécessaires est la classe Catalogue. On lui ajoute donc cette méthode de recherche de livre.

Facturation[modifier | modifier le wikicode]

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

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é de calculer le total de la facture ?

La classe ProduitFacturé connaît l'article utilisé et la quantité commandée. On lui ajoute une méthode sousTotal() qui demandera le prix unitaire à l'Article et le multipliera par la quantité.

La classe Facture connaît la liste de tous les produits facturés. On lui ajoute une méthode total() qui effectue la somme des sous-totaux demandés aux différentes instances de la classe ProduitFacturé en appelant la méthode sousTotal().

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

Cet exemple démontre également que ce patron de conception favorise l'encapsulation : Une classe n'a pas besoin de connaître la structure interne de la classe Facture pour calculer le montant total dû.