[Conception]Design Pattern Factory ?

Salut,

J'ai une question concernant le nom du design pattern utilisé:

Code:

---

1 2 3

public interface PlayerFactory { Player createPlayer(); }

---

Code:

---

1 2 3

public interface ExternalPlayerFactory extends PlayerFactory {   }

---

C'est une classe qui permet de "construire" un objet particulier...

Je dirais que ça ressemble à Factory, mais pour moi Factory, c'est toujours une (et une seule) classe qui contient une méthode static createMachin()... et non une classe qui peut être instanciée pour créer ces objets...

Vous en pensez quoi??

Sinon, j'ai pensé à Builder, mais c'est pas tout à fait ça ...

Une factory est une classe permettant de fabriquer (instancier) des objets (souvent d'un même type).

Cette classe n'est pas obligé d'avoir une et une seule méthode. Ses méthodes ne sont pas obligées d'être static.

Dans tous les projets que j'ai recontrai, les factory étaient des Singletons avec des méthodes normales.

Par exemple :

Code:

---

1 2 3 4 5 6 7

public class EmployeFactory() { public Employe createEmploye(int typeEmploye) { ...} public Employe createSecretaire() { ...} public Employe createCommercial() { ...} public Employe createInformaticien() { ...} }

---

Un exemple de l'api Java : javax.swing.BorderFactory

A+

OK, je les nomme Factory alors :)

Concernant BorderFactory, il n'y a que des méthodes statiques :)

Concernant les méthodes statiques ou non tu as deux possibilités :
- soit tu mets toutes les méthodes en statiques
- soit ta classe est un singleton.

Je disais juste que dans les projets que j'ai développé (maintenu), je n'avais trouvé que des Singletons.

Pour trouvé l'exemple de BorderFactory, j'ai recherché Factory dans la javadoc.

A+

Par ce que ce n'est plus le pattern Factory mais son evolution : le pattern Abstract Factory qui permet de changer de fabrique. Hors on ne peut pas faire ce pattern avec des methodes statiques.

Citation:

---

Par ce que ce n'est plus le pattern Factory mais son evolution : le pattern Abstract Factory qui permet de changer de fabrique. Hors on ne peut pas faire ce pattern avec des methodes statiques.

---

Certainement pas : AbstractFactory n'est en aucun cas une évolution de Factory !!! Le nom GOF de ce que vous appelez "Factory" est "Factory Method" (traduit en fabrication, ou encore méthode de fabrication). En général, AbstractFactory est implémenté en utilisant une FactoryMethod (plusieurs même !!!), mais il existe d'autre moyens de faire. Je ne saurai trop vous conseiller le "design pattern" de Gamma, Johnson, Vlissides et Helm.
Sachez enfin qu'en général, une AbstractFactory est un singleton (ça été dit, je le confirme).

Citation:

---

Envoyé par Patriarch24

Certainement pas : AbstractFactory n'est en aucun cas une évolution de Factory !!! Le nom GOF de ce que vous appelez "Factory" est "Factory Method" (traduit en fabrication, ou encore méthode de fabrication). En général, AbstractFactory est implémenté en utilisant une FactoryMethod (plusieurs même !!!), mais il existe d'autre moyens de faire. Je ne saurai trop vous conseiller le "design pattern" de Gamma, Johnson, Vlissides et Helm.
Sachez enfin qu'en général, une AbstractFactory est un singleton (ça été dit, je le confirme).

---

Donc mon interface, si je l'appelle PlayerFactory, c'est bon?

Arf, exact, merci de m'avoir forcé à re-regardé de plus près quelque chose que je croyais acquis depuis longtemps... hum donc mes profs s'étaient plantés il y a 8 ans. On dit AbtractFactory, non pas parceque la fabrique est abstraite/interface et qu'on utilise des implémentations concrètes de cette fabrique pour générer des objets mais car elle permet de créer des objets de type abstrait.

Citation:

---

Envoyé par Design Pattern Explained

At first glance, you might be tempted to conclude it is because the factory is implemented as an abstract class with derivation for each case. But that is not the case. This pattern is called the "Abstract Factory" because the things it is intended to build are themselves debined by abstractions [...] How do you choose to implement the factory variations is not specific to the patter.

---

BorderFactory se qualifie donc bien comme AbstractFactory malgrès ses méthodes statiques.

Pour FactoryMethod en Java il faut voir du côté de la génération des Iterator par exemple.

Citation:

---

Envoyé par Design Pattern Explained

In Java, the iterator method on collections is a Factory method. This method returns the right type of iterator for the collection being asked for.

---

Cependant, franchement, ces deux concepts de patterns créationistes sont similaires à 90% : on retourne une abstraction en créant un objet (ou une collection d'objets) spécifique(s) à un usage particulier. Seule la mise en oeuvre est (légèrement et très superficiellement) différente.

Citation:

---

Cependant, franchement, ces deux concepts de patterns créationistes sont similaires à 90% : on retourne une abstraction en créant un objet (ou une collection d'objets) spécifique(s) à un usage particulier. Seule la mise en oeuvre est (légèrement et très superficiellement) différente.

---

L'objectif d'une AbstractFactory est de créer une famille de produits coopérant ensemble. Le but d'une AbstractFactory est de pouvoir changer de famille de produits, en changeant de fabrique.

Exemple (tiré du design patterns de GHJV) :
tu as une classe (ou une interface, c'est selon) WidgetFactory (fabrique abstraite), de laquelle dérivent les classes MotifWidgetFactory et PMWidgetFactory. Chacune définit les méthodes CreateScrollBar et CreateWindow (il s'agit de FactoryMethod !). Cet ensemble constitue les fabriques (interchangeable selon qu'on utilise Motif ou PM (Presentation Manager).
Ensuite, on a les produits :
les interfaces Window et ScrollBar, d'où dérivent PMWindow et MotifWindow, et PMScrollBar et MotifScrollBar respectivement.

Le principe est que si tu utilises une PMWidgetFactory, tu créeras les objets
PMWindow et PMScrollBar, et que si tu utilises une MotifWidgetFactory, tu créeras des MotifWindow et des MotifScrollBar. D'où le concept de famille qui n'est pas présent dans le cas d'une FactoryMethod (qui n'est rien d'autre qu'une... méthode !). Cela implique la nécessité de posséder une fabrique concrète par famille de produit.

A noter qu'on peut implémenter une fabrique abstraite avec le modèle prototype. Dans ce cas, on initialise la fabrique avec les produits qui vont bien, et on fait des copies de ces produits (ça évite d'avoir une fabrique concrète par famille :) ). Mais c'est quand même nettement plus complexe.

La similarité entre AbstractFactory et FactoryMethod tient au fait qu'en général AbstractFactory est implémenté avec des FactoryMethod.

Le nom de Factory peut être utilisé pour la fabrication de Player (c'est bien une fabrique concrète d'ailleurs, mais qui ne gère qu'un seul type de produit).