[Factory Method] Questions

Bonjour à tous,
J'ai quelques questions sur le DP Factory method dont je ne trouve pas les réponses...si une âme charitable pouvait m'éclairer...:oops:

D'aprés ce que j'ai compris et cela me semble logique, il n'est pas bon d'instancier une classe (on va dire Produit) directement avec le mot clé new dans le code d'une classe Cliente. Il est aussi préférable d'utiliser des classes abstraites ou interfaces afin que notre classe cliente puisse fonctionner avec toutes les sous classes de Produit, autrement dit developper pour une interface et non pas pour une implementation.

Pour suivre ces conseils, on utilise le pattern Factory method qui définit une interface pour la création d'un objet( on va dire un objet de la classe Produit), mais en laissant à des sous classes le choix des classes à instancier ProduitContretA, ProduitConcretB...

Voila mon souci :oops: : J'ai bien compris ces principes qui me semblent logiques, ce que je ne comprends pas, c'est comment le client peut utiliser ces fabrications sans en être couplé a ces dernières...
Autrement dit, si j'utilise une Fabrication (FabricationConcreteA) qui hérite d'une interface ou d'une classe abstraite (Fabrication) et qu'il arrive demain qu'il faille que je change de Fabrication(FabricationConcretB), je me retrouve dans le meme souci, il faut que je cherche dans mon code toutes les instantiations :aie: ,ce que je veux dire par la, c'est que j'ai l'impression qu'on a seulement repoussé le problème, notre code n'est plus couplé aux produits mais aux fabrications :oops:

A moins que les fabrications ne puissent etre utilisé qu'avec le pattern fabrication Absraite...

Je ne sais pas si j'ai été clair, enfin si vous pouviez me donner des tuyaux sur votre façon de les utiliser cele serait trés sympa...

Merci

Citation:

---

Envoyé par Aïssa

A moins que les fabrications ne puissent etre utilisé qu'avec le pattern fabrication Absraite...

---

Oui, c'est exactement ca:

- Les "clients" ne connaissent que la definition de l'interface (ProduitInterface), donc ils ne sont pas liés aux differentes implémentations (ProduitContretA, ProduitContretB, ...).

- Les implémentations, elles, ne connaissent pas du tout les clients.

- Le lien est fait par la Factory, qui connait et instancie l'implémentation (par ex. ProduitContretA) mais ne renvoie aux clients que l' interface (ProduitInterface). Donc ton client a juste besoin de connaitre l'interface et la factory.

En cas de création d'une nouvelle implementation, tu as juste a changer le code dans la Factory. Au lieu de faire un "new ProduitContretA()" tu fais un "new ProduitContretB()", et dans tous les cas tu retourne un "ProduitInterface" :)

Merci pseudocode de ta réponse :D

En fait, je m'étais posé la question car dans l'exemple donné dans le bouquin "Head first design pattern", le client instantiait directement la fabrique qu'il souhaitait avoir pour générer le produit qu'il souhaitait.
Même dans le fameux bouquin d'Erich Gamma GOF (design Patterns), pour créer des variétés de son labyrinthe, il hérite de sa factory, mais il ne montre pas comment elles sont appelées par le client, enfin je pense qu'il les instantie directement, donc je me demandais quel était l'utilité de coupler son code avec une fabrique qui peut changer dans l'avenir...

C'est vrai que les exemples sont habituellement fait pour expliquer le "principe" de la Factory, mais pas son utilisation dans une application.

Personnellement, je prefere faire une factory "configurable" (DP Factory + DP Strategy). Au lancement de l'application, je configure la factory en lui indiquant le nom de la classe concrete a instancier:

Code:

---

ProductFactory.setConcretClass( ConcretProductA.class );

---

Ensuite, tous les clients font des

Code:

---

Product p = new ProductFactory().getNewProduct();

---

Certains preferent mettre la factory dans un singleton, plutot que de l'instancier a chaque fois. Mais apres il faut gerer les problemes de concurence de thread... :aie:

Merci pseudoCode pour ton éclairage ;-)