Le modèle fabrication(Factory Method Pattern)

Le pattern factory method selon l'ouvrage "Design Patterns: Elements of Reusable Object-Oriented Software" du GOF.

Alias

• Fr : modèle fabrication, Constructeur Virtuel
• Angl : factory method pattern, virtual constructor

Intention de factory method

Le pattern factory method définit une interface pour la création d'un objet en laissant à des sous-classes le choix des classes à instancier.

Motivation de factory method

Les frameworks utilisent des classes abstraites pour définir et gérer les relations entre les objets. Un framework est souvent responsable de la création de ces objets.

Considérons un framework pour des aplications qui présentent des documents multiples à l'utilisateur. Deux clés abstraites fondamentales de ce framework sont les classes Application et Document. Nous devons dériver des sous-classes concrètes pour réaliser les implémentations spécifiques de ces deux classes. Pour créer une application de dessin par exemple, nous devons créer les classes DrawingApplication et DrawingDocument. La classe Application est responsable de la gestion des Documents, et de leur création si nécessaire - lorsque l'utilisateur sélectionne Open ou New dans un menu, par exemple.

Puisque la sous-classe particulière de Document à instancier est dépendante du type d'application, la classe Application ne peut prévoir la sous-classe de Document qu'il convient d'instancier - la classe Application connait seulement le moment où un Document doit être créé, mais pas le type de Document à créer. Cette situation crée un dilemne : le framework doit instancier des classes, mais il ne connait que des classes abstraites, qui ne peuvent être instanciées.

Le factory method pattern nous offre donc une solution : encapsuler la connaissance du type de sous-classe de Document à créer, et déplacer cette connaissance hors du framework.

Les sous-classes d'Application redéfinissent par surcharge une opération abstraite d'Application nommée createDocument, afin de retourner la sous-classe de Document qui convient. Dès qu'une sous-classe Application est instanciée, elle peut à son tour instancier des Documents spécifiques de l'Application, sans connaître leur classe. La méthode createDocument est une factory method car elle est responsable de la fabrication d'un objet.

Utilisation de factory method

Le modèle fabrique peut nous aider dans les cas suivants :

• Une classe ne peut prévoir la classe des objets qu'elle devra créer.
• Une classe désire que ses sous-classes spécifient les objets qu'elle crée
• Les classes délèguent des responsabilités à une de leurs nombreuses sous-classes assistantes, et nous désirons localiser le fait de savoir quelle sous-classe assistante a reçu cette délégation.

Structure de factory method

Constituants de factory method

• Product (produit abstrait ou interface)
  Définit l'interface des objets créés par l'opération factoryMethod. Dans le cadre de notre exemple, le produit est Document.
• ConcreteProduct (produit concret)
  Implémente l'interface Product. Dans le cadre de notre exemple, le produit concret est MyDocument.
• Creator (facteur - )
  Déclare l'opération factoryMethod qui retourne un objet de type Product. Creator peut aussi définir une implémentation par défaut de factoryMethod, qui retourne un objet ConcreteProduct par défaut. Il peut en outre faire un appel à factoryMethod pour créer un objet Product. Dans le cadre de notre exemple, le facteur est Application.
• ConcreteCreator (facteur concret)
  Override (surcharge) l'opération factoryMethod pour retourner une instance du ConcreteProduct approprié. Dans le cadre de notre exemple, le facteur concret est MyApplication.

Collaborations de factory method

Creator confie à ses sous-classes le soin de la définition de la fabrication, de sorte qu'il renvoie une instance du ConcreteProduct approprié.

Conséquences de factory method

Avantages du factory method pattern :

Factory method pattern élimine le besoin d'incorporer des classes spécifiques à l'application dans notre code. Le code ne concerne que l'interface Product; nous pouvons le faire fonctionner avec toute classe produit concret que nous définissons, pourvu qu'elle implémente Product.

Un inconvénient potentiel des méthodes factory réside dans le fait que les clients peuvent avoir à dériver (sous-classer) la classe Creator simplement pour créer un objet produit concret particulier. Sous-classer peut être rentable lorsque nous devons de toute manière dériver des sous-classes de Creator.

Hébergement des sous-classes. Nous pouvons plus aisément créer des objets à l'intérieur d'une classe à l'aide d'une méthode factory que de les créer directement.

Interconnection des hiérarchies parallèles de classes. Nous avons des hiérarchies de classes parallèles quand une classe délègue certaines de ses responsabilités à une classe séparée.

Implémentation de factory method

Deux variantes principales :

• Creator est une classe abstraite et ne fournit pas d'implémentation pour la fabrication qu'elle déclare.
• Creator est une classe concrète qui fournit une implémentation par défaut pour la fabrication.

NB : nous pouvons aussi plus rarement trouver le cas d'une classe abstraite qui fournit une implémentation par défaut.

Fabrication paramétrée. Dans ce cas, nous permettons à la méthode factory de créer de nombreuses espèces de produits. La méthode factory utilise alors un paramètre pour déterminer le type d'objet à créer, pourvu que chaque type implémente Product.

Exemples de codes

using System;
class Document
{
public :
virtual void setPosition( int x, int y ) =0 ;
virtual void redisplay() =0 ;
//...
} ;
class Application
{
public :
int run()
{
//...
newDocument() ;
//...
moveDocument(3,5) ;
//...
}
protected :
virtual void newDocument() =0 ;
Document * doc_ ;
private :
void moveDocument( int x, int y )
{
doc_->setPosition(x,y) ;
doc_->redisplay() ;
}
} ;
//...
class WordDocument : public Document
{
public :
void setPosition( int x, int y ) { /***/ }
void redisplay() { /***/ }
//...
}
class Word : public Application
{
protected :
void newDocument() { doc_ = new WordDocument ; }
}
int main()
{
Word appli ;
appli.run() ;
}

public abstract class Editor {
private Document doc;
public abstract Document createDocument();
public void newDocument() {
doc = createDocument();
doc.open();
}
public void saveDocument() {
if (doc != null)
doc.save();
}
public void closeDocument() {
if (doc != null)
doc.close();
}
}
public class RTFEditor extends Editor {
public Document createDocument() {
return new RTFDocument();
}
}
public abstract class Document {
public abstract void open();
public abstract void save();
public abstract void close();
}
public class RTFDocument extends Document {
public void RTFDocument() {
System.out.println("RTF Document Created");
}
public void open() {
System.out.println("RTF Document Open");
} 
public void save() {
System.out.println("RTF Document Saved");
}
public void close() {
System.out.println("RTF Document Closed");
}
}
public class Main {
public static void main(String[] args) {
Editor editor = new RTFEditor();
editor.newDocument(); 
editor.saveDocument();
editor.closeDocument();
}
}

Patterns apparentés au factory method

Abstract Factory
Template Methods
Prototype

Structure du document