# Patrons de conception/Expert en information

* Introduction
* Patrons du « Gang of Four »
** Patrons de création
*** Singleton
*** Prototype
*** Fabrique
*** Fabrique abstraite
*** Monteur
** Patrons de structure
*** Pont
*** Façade
*** Adaptateur
*** Objet composite
*** Proxy
*** Poids-mouche
*** Décorateur
** Patrons de comportement
*** Chaîne de responsabilité
*** Commande
*** Interpréteur
*** Itérateur
*** Médiateur
*** Mémento
*** Observateur
*** État
*** Stratégie
*** Patron de méthode
*** Visiteur
* Patrons GRASP
** Expert en information
** Créateur
** Faible couplage
** Forte cohésion
** Contrôleur
** Polymorphisme
** Fabrication pure
** Indirection
** Protection
* Patrons d'entreprise
** Logique du domaine
*** Script de transaction
*** Modèle du domaine
*** Module de table
*** Couche de service
** Architecture de source de données
*** Passerelle de table de données
*** Passerelle de ligne de données
*** Enregistrement actif
*** Gestion de données
** Comportement objet-relationnel
*** Unité de travail
*** Carte d'identité
*** Chargement différé
** Structure objet-relationnel
** Association méta-données objet-relationnel
** Présentation web
** Distribution
** Concurrence locale (hors-ligne)
** État de session (Session State Patterns)
** Patrons de base
*** Passerelle (Gateway)
*** Mapper
*** Type de base pour la couche
*** Interface séparée
*** Registre
*** Plugin
*** Objet valeur
*** Monnaie
*** Cas spécial
*** Service de substitution
*** Ensemble d'enregistrements
* Autres patrons
** Type fantôme
** Double-dispatch
** Post-Redirect-Get
** Map-Reduce
** Évaluation retardée
** Copie sur modification
** Injection de dépendance
** Inversion de contrôle
** Modèle-Vue-Contrôleur
** Modèle-Vue-Présentateur
** Écart de génération
** Objet nul
** Objets réutilisables
** Outbox
** Feature toggles
* Bibliographie et liens
* Introduction
* Patrons du « Gang of Four »
** Patrons de création
*** Singleton
*** Prototype
*** Fabrique
*** Fabrique abstraite
*** Monteur
** Patrons de structure
*** Pont
*** Façade
*** Adaptateur
*** Objet composite
*** Proxy
*** Poids-mouche
*** Décorateur
** Patrons de comportement
*** Chaîne de responsabilité
*** Commande
*** Interpréteur
*** Itérateur
*** Médiateur
*** Mémento
*** Observateur
*** État
*** Stratégie
*** Patron de méthode
*** Visiteur
* Patrons GRASP
** Expert en information
** Créateur
** Faible couplage
** Forte cohésion
** Contrôleur
** Polymorphisme
** Fabrication pure
** Indirection
** Protection
* Patrons d'entreprise
** Logique du domaine
*** Script de transaction
*** Modèle du domaine
*** Module de table
*** Couche de service
** Architecture de source de données
*** Passerelle de table de données
*** Passerelle de ligne de données
*** Enregistrement actif
*** Gestion de données
** Comportement objet-relationnel
*** Unité de travail
*** Carte d'identité
*** Chargement différé
** Structure objet-relationnel
** Association méta-données objet-relationnel
** Présentation web
** Distribution
** Concurrence locale (hors-ligne)
** État de session (Session State Patterns)
** Patrons de base
*** Passerelle (Gateway)
*** Mapper
*** Type de base pour la couche
*** Interface séparée
*** Registre
*** Plugin
*** Objet valeur
*** Monnaie
*** Cas spécial
*** Service de substitution
*** Ensemble d'enregistrements
* Autres patrons
** Type fantôme
** Double-dispatch
** Post-Redirect-Get
** Map-Reduce
** Évaluation retardée
** Copie sur modification
** Injection de dépendance
** Inversion de contrôle
** Modèle-Vue-Contrôleur
** Modèle-Vue-Présentateur
** Écart de génération
** Objet nul
** Objets réutilisables
** Outbox
** Feature toggles
* Bibliographie et liens
[ Modifier le sommaire ]
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
### Bibliothèque

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

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.
* Facture
* + client
* ProduitFacturé
* + quantité
* Article
* + nom
* + prix_unitaire
* + 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û.