- Forte
- Intermédiaire
Le design pattern Fabrique (Factory Method) définit une interface pour la création d'un objet en déléguant à ses sous-classes le choix des classes à instancier.
Description du problème
Il est fréquent de devoir concevoir une classe qui va instancier différents types d'objets suivant un paramètre fourni. Par exemple une usine va fabriquer des produits en fonction du modèle qu'on lui indique.
L'idée la plus simple pour répondre à ce besoin est d'écrire une succession de conditions qui suivant le modèle demandé, instancie et retourne l'objet correspondant.
Le problème avec cette implémentation, c'est que la classe correspondant à l'usine va être fortement couplée à tous les produits qu'elle peut instancier car elle fait appel à leurs types concrets.
Or ce code va être amené à évoluer régulièrement lors de l'ajout de nouveaux produits à fabriquer ou de la suppression de certains produits obsolètes.
De plus, il est fort probable que l'instanciation des différents produits soit également réalisée dans d'autres classes par exemple pour présenter un catalogue des produits fabriqués.
On se retrouve alors avec du code fortement couplé, qui risque d'être dupliqué à plusieurs endroits de l'application.
Début de solution
La première solution est de regrouper l'instanciation de tous les produits dans une seule classe chargée uniquement de ce rôle. On évite alors la duplication de code et on facilite l'évolution au niveau de la gramme des produits.
Cette solution appelée Fabrique Simple est une bonne pratique de conception mais pas un design pattern. En effet, le design pattern Fabrique est plus évolué et offre plus de flexibilité, donc attention à ne pas les confondre. Pour autant cette bonne pratique est régulièrement utilisée et s'avère efficace dans les cas les plus simples (voir son diagramme UML ci-dessous).

L'utilisateur du produit fait appel à la Fabrique Simple pour obtenir un Produit. C'est la Fabrique Simple qui est chargée d'instancier et de retourner le Produit Concret attendu (par exemple grâce à un paramètre passé en argument de la fonction). L'utilisateur du produit est donc fortement couplé uniquement à la Fabrique Simple et non à tous les produits qu'il prend en charge.
Si par la suite l'entreprise évolue et a besoin de plusieurs usines, chacune spécialisée dans la fabrication de certains produits, Fabrique Simple ne va plus suffire.
Dans ce cas il faut prévoir l'utilisation du design pattern Fabrique dont le diagramme UML est présenté ci-dessous.
Diagramme UML

Définition de la solution
Le créateur contient toutes les méthodes permettant de manipuler les produits exceptée la méthode creerProduit qui est abstraite. Les créateurs concrets implémentent la méthode creerProduit qui instancie et retourne les produits. Chaque créateur concret peut donc créer des produits dont il a la responsabilité. Pour finir tous les produits implémentent la même interface afin que les classes utilisant les produits (comme le créateur) puissent s'y référer sans connaître les types concrets.
Suivant les besoins, l'interface Produit peut être une classe abstraite. Il est également bénéfique d'utiliser ce pattern même si l'on a qu'un seul CreateurConcret ou qu'un CreateurConcret n'instancie qu'un seul Produit car les avantages liés au découplage des produits et du créateurs sont conservés.
A noter que les créateurs concrets utilisent la bonne pratique Fabrique Simple présentée précédemment. Mais comparé à cette bonne pratique qui ne sert qu'une fois, le design pattern Fabrique permet de créer une structure où l'ajout d'une sous classe (c'est à dire un créateur concret) permet de choisir les produits qui seront utilisés. C'est d'ailleurs ce qui explique la définition de ce pattern.
Conséquences
Le pattern Fabrique doit être utilisé pour découpler les clients des classes concrètes à instancier, ou si l'on ne connaît pas d'avance toutes les classes concrètes à instancier.
Pour créer des familles de produits cohérentes, on sera amené à utiliser le design pattern Fabrique Abstraite qui répond spécifiquement à ce besoin.

Salut à tous les membres.
Encore merci à toi Mathieu. Mais je voulais rebondir sur la partie 'Definition de la solution': pour moi, on a deux types de méthodes à définir dans le createur:
-les méthodes abstraites qui sont toutes les méthodes qui seront redéfinites par chaque produit en fonction de leurs besoins.
- les methodes non abstraites qui ont un implémentation commune d'un produit à l'autre.
-Et je vois un constructeur dans chaque produit à la place de la méthode creerProduit.
Salut Cedric,
Je te confirme, dans la classe abstraite Createur on retrouve bien :
- au moins une méthode abstraite qui sera chargée d'instancier les produits (c'est la définition même du pattern Fabrique)
- éventuellement des méthodes concrètes dont l'implémentation est commune à tous les produits (donc basée sur les attributs et les méthodes de la classe abstraite Produit).
Puis, chaque produit concret a son propre constructeur (qui peut éventuellement être vide) et qui sera appelé lors de l'instanciation de celui-ci dans l'implémentation de la méthode creerProduit().
Si un point ne te semble pas clair n'hésite pas à poster un nouveau commentaire :)
C'est plus claire à présent.
Très bien expliqué.
Tu devrais faire plus de tutos sur les divers patterns. Y en a pas assez, même si c'est vrai que tu présentes les principaux, d'autres seraient utiles (strategy, MVC, etc.)
Beau boulot.
Merci pour tes encouragements.
Je compte bien continuer à présenter les autres design patterns petit à petit.
Merci pour ce tuto, vraiment agréable et facile à comprendre, c'est très clair. Merci beaucoup.
(et j'attends tes autres articles sur d'autres design patterns!)
Merci pour l'article, il m'a beaucoup eclairé ^^
Enfin, je comprends clairement le truc (au moins, le cinquième site dont je lis les explications).
Merci beaucoup
Merci pour le tutoriel.
Il serait mieux de présenter les autres patterns surtouts les fondamentales aux projets standards, déjà ceux présentés ne sont pas nombreux.
Nous voulons bien profiter de ta manière aussi simple de simplifier le problème.
Merci.
Merci à tous pour vous encouragements.
L'explication du design pattern Fabrique Abstraite est en préparation.
A bientôt.
Merci pour cette explication claire, basique, mais qui nous instruit tellement mieux qu'une tonne de texte qui ne veut rien dire. Grâce à vous, je comprends enfin certain design-pattern ainsi que leurs utilités.
En espérant que vous continuerez dans l'explication de design-patterns.
Je suis heureux d'avoir pu vous être utile et j'espère pouvoir continuer.
Merci pour votre commentaire
Merci pour ce tuto