Discussion :

[Rhukon]

Bonjour,

Après avoir vu le fonctionnement des design patterns factory et abstract factory, je n'arrive pas à comprendre ce qu'apporte l'abstract factory.

J'ai fait pas mal de recherches et ai comparé des codes d'exemple (dispo ici dans headfirst\factory\pizzafm et pizzaaf : http://headfirstlabs.com/books/hfdp/...code102507.zip), mais ca ne répond pas à ma question... puisqu'a l'utilisation les 2 sont identiques.

J'ai un peu l'impression que l'abstract factory complexifie le code et n'apporte rien

Quelque chose doit m'échapper...

[Patriarch24]

Une fabrique abstraite ("abstract factory") sert à créer une famille d'objet.

Par exemple, pour une fabrique d'objet graphiques, tu peux avoir à créer des boutons, des widgets quelconques, des fenêtres etc pour différents systèmes de fenêtrage. Et bien tu auras une fabrique (concrète cette fois-ci) par système (ex : Motif, MS-Windows, Mac OS, ...). Chacune des ces fabriques pourra créer les widgets de la famille adéquate.

Par ailleurs, "factory" n'est pas un nom de design pattern, tu dois parler de "factory method" (méthode de fabrication ou création), qui comme son nom l'indique, consiste à créer un objet via un objet tiers. Une fabrique abstraite utilise généralement des méthodes de fabrication !

[Rhukon]

Merci pour cette réponse

Effectivement, je parlais de factory method .

J'ai compris que la factory method était utilisée par l'abstract factory.

Tu voudrais dire que la différence entre la factory method et l'abstract factory,
est que l'abstract factory instancie plusieurs objets en une seule fois, au lieu d'un seul pour la factory method ?

[Patriarch24]

Tu voudrais dire que la différence entre la factory method et l'abstract factory,
est que l'abstract factory instancie plusieurs objets en une seule fois, au lieu d'un seul pour la factory method ?

C'est même plus fort que cela : une fabrique abstraite fabrique des objets ayant une relation forte (par exemple des widgets Win32, tandis qu'une autre implémentation fabriquera des widgets Mac OS).

Ces deux patterns sont des patterns de création.

[Rhukon]

Patriarch24, je crois que tu as éclairé ma lanterne

Donc si j'ai bien compris:
La factory method permet de déporter la création d'objets dans une autre classe, dédiée.
L'abstract factory utilise une ou plusieurs factory method pour créer un objet plus complexe, composé d'autres objets.

En reprenant le cours de JMDoudoux, dans les diagrammes de classe de ces 2 patterns les 2 classes 'client' ne sont donc pas les mêmes. Pour la methode frabrique, client correspond à la classe instanciée à l'execution du programme (d'ou le main) tandis que pour la fabrique abstraite, client est la classe instanciée, composée de 2 objets produitB et produitA .

Si quelqu'un pouvais me confirmer que je n'ai rien manqué d'important...

Merci

[Patriarch24]

L'abstract factory utilise une ou plusieurs factory method pour créer un objet plus complexe, composé d'autres objets.

Pas forcément. Ce que tu décris est un Monteur, qui lui est spécialisé dans la construction d'objet composé. Une Fabrique Abstraite construit des objets liés, mais pas forcément constituant un objet composé.

[Rhukon]

Donc l'intérêt de la fabrique abstraite est de pouvoir choisir quel classe instancier, tandis que dans la factory method l'instanciation dépend des sous classes ?

[wiztricks]

Salut,
La difficulté des DP est qu'il s'agit de concepts que les exemples illustrent plus ou moins bien.

Techniquement, une "fabric method" retourne une instance de:

• une sous classe de la classe correspondante (à la method). Dans ce cas, on peut parler de famille d'objets associés à la 'fabric method'; ou
• une instance de la classe et dans ce cas se substitue, remplace le constructeur.

Cas particuliers: comment appeler les fabric method de Singleton ou de FlyWeigth?

Techniquement, les methods d'une "abstract fabric" retournent une instance d'une des familles associées via les 'fabric methods' correspondantes. De fait, l'abstract fabric regroupe les différentes familles de façon analogue à un catalogue.

A priori, les détails de la construction des différents objets 'derrière' la fabric devraient pouvoir être ignorés...
La fabrique retournera l'instance d'un modèle particulier: elle n'a pas le choix et ce qu'elle soit abstract ou pas.

(Mauvais) exemples: On a une classe "Voiture" et des sous-classes définies par les différents modèles de... Et une classe Vélo avec des sous-classes...

L'intérêt des 'fabric' est de dissocier l'appelant qui pourra utiliser Velo ou Voiture dans ce qu'ils ont de communs même si dans la vraie vie un modèle particulier leur sera retourné.

Pourquoi? Outre que cela permette d'ajouter de nouveau modèles tous les ans sans casser la logique, cela permet de penser indépendamment à la construction des vélos et à leur utilisation.

Accessoirement s'assurer que la représentation de Vélo ou de Voiture - celle indépendante d'un modèle particulier - est/sera efficace.

Côté écriture du code, çà permet de paralléliser et de tester plus facilement.

On peut faire un parallèle entre classe/constructeur/instances et Vélo/Fabrique/Modèles au sens ou Vélo/Voiture sont des abstractions des différents 'modèles' de vélos ou de voitures.

Note: Les exemples concrets sont généralement plus parlants même s'ils sont aussi faux que les exemples de code...

Tu peu aussi voir les cours et tutoriels de formation pour apprendre la langage Java : http://java.developpez.com/cours/

- W

[Rhukon]

Merci pour ces précisions. C'est pas évident de comprendre vraiment l'utilité de certains patterns.

Merci à vous deux, c'est beaucoup plus clair