Factory Method

Intention
Le patron Factory Method définit une interface pour la création d’un objet, mais en
laissant à des sous-classes le choix des classes à instancier.

Il permet à une classe de déléguer l’instanciation à des sous-classes.

Objectif :

Laisser le développeur définir l’interface permettant de créer un objet tout en gardant

un contrôle sur le choix de la classe à instancier.

Un exemple classique consiste à permettre la construction d'un objet d'image à partir

de son nom de fichier :
● Le problème étant que la manière de charger (ou sauvegarder) une image est
dépendante de son type (gif, jpg, png, ...) et donc de l'extension du fichier.
Problème
Comme pour le patron Simple Factory, Factory Method vise à résoudre un problème
fondamental lors de l’instanciation, c’est-à-dire la création d’un objet concret d’une
classe.

Dans la programmation orientée objet, créer un objet directement au sein de la

classe, qui a besoin de cet objet ou devrait l’utiliser, est possible en principe, mais
reste très rigide. Il lie la classe à cet objet particulier et rend impossible le fait de
modifier l'instanciation indépendamment de la classe.
Solution
Factory method évite de lier une classe à un object en définissant d'abord une
opération distincte pour la création de l'objet : la fabrique. Une fois appelée, elle
génère l’objet, au lieu du constructeur de la classe.
Principe de base du patron Factory Method
Structure

Diagramme UML du patron Factory Method

Participants
● Product définit l'interface des objets créés par la fabrication;
● ConcreteProduct implémente l'interface Product;
● Creator déclare la fabrication, celle-ci renvoie un objet de type Product. Le
Creator peut également définir une implémentation par défaut de la
fabrication, qui renvoie un objet ConcreteProduct par défaut. Il peut appeler la
fabrication pour créer un objet Product;
● ConcreteCreator surcharge la fabrication pour renvoyer une instance d'un
ConcreteProduct.

Collaborations & implémentation

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

Pour l’implémentation, nous avons 2 variantes principales :

● La classe Creator est une classe abstraite et ne fournit pas d'implémentation
pour la fabrication qu'elle déclare (les sous-classes définissent
obligatoirement une implémentation).
● La classe Creator est une classe concrète qui fournit une implémentation par
défaut pour la fabrication;
● Fabrication paramétrée : la fabrication utilise un paramètre qui identifie la
variété d'objet à créer.

Remarques :

La fabrication dispense d'avoir à incorporer à son code des classes spécifiques de

l'application. Le code ne concerne que l'interface Product, il peut donc fonctionner
avec toute classe ConcreteProduct définie par l'utilisateur.

la création d'objets à l'intérieur d'une classe avec la méthode fabrication est toujours
plus flexible que la création d'un objet directement.

La Figure ci-dessous illustre la différence structurelle entre les patrons Simple

Factory et Factory method.
 Simple Factory
vs Factory Method

Comparé à simple Factory dans lequel l'usine est responsable de la production de

tous les produits, Factory Method distribue la tâche de génération des produits
spécifiques à des usines de produits spécifiques.

En d'autres termes, Factory Method définit l’usine abstraite, qui définit l'interface de
production du produit, mais ne prend pas en charge le produit spécifique, et confie
les tâches de production à différentes usines de classes dérivées. Cela élimine le
besoin de créer des objets en spécifiant le type.

Les développeurs simplifient souvent le modèle en retirant l'interface de fabrique :

On ne considère plus que la classe d'implémentation de la Factory, qui peut aussi
être un Singleton.

Une autre simplification consiste à transformer la méthode de fabrique en une

méthode statique directement portées par l'interface de produit.
Exemple illustratif
Continuons toujours avec l’exemple de fabrication de téléphones portables pour
expliquer le patron Fatory Method.

Les classes IPhone, Samsung et l'interface Phone liées au produit restent inchangées.

Nous définissons les classes suivantes :

Classe AbstractFactory : une classe abstraite pour les usines qui fabriquent différents
produits.
public interface AbstractFactory {
Phone makePhone();
}

Classe SamsungFactory : l'usine qui produit les téléphones portables Samsung

(ConcreteFactory1).
public class SamsungFactory implements AbstractFactory{
@Override
public Phone makePhone() {
return new Samsung();
}
}

Classe AppleFactory : l'usine qui produit les téléphones portables Apple

(ConcreteFactory2).
public class AppleFactory implements AbstractFactory {
@Override
public Phone makePhone() {
return new IPhone();
}
}

Cas utilisation :
public class Client {
 public static void main(String[] arg) {
AbstractFactory samsungFactory = new
SamsungFactory();
AbstractFactory appleFactory = new AppleFactory();
samsungFactory.makePhone(); // make samsung
phone!
appleFactory.makePhone(); // make iphone!
}
}

Diagramme UML du code ci-dessus

Bien que nous ayons résolule le problème d’ajout d’un autre type de produit dans le
patron Simple Factory, nous pouvons constater que la classe que nous avons écrite
est beaucoup plus grande.
Bien que nous n'ayons pas besoin de modifier le code dans la classe d'usine, nous
devons recréer une usine (par exemple, pour créer une usine Samsung, celle-ci doit
implémenter la classe AbstractFactory).
Usages connus
● Les toolkits les frameworks car leurs classes sont souvent dérivées par les
applications qui les utilisent.
● Des hiérarchies de classes parallèles peuvent avoir besoin d'instancier des
classes de l'autre.
● Création des collections immuables en Java, Factory Method est utilisé pour
créer List, Set, Map et Map.Entry.
Avantages et inconvénients
Avantages
● Le patron Factory Method élimine le besoin d'incorporer des classes
spécifiques à l'application dans notre code.
● La méthode de programme est complètement séparé de l’implémentation de
nouvelles classes.
● En termes d’extensibilité d’un logiciel, les instances du patron permettent
d’ajouter de nouvelles classes sans que l’application ait à changer.

Inconvénients
● Chaque ProduitConcret nécessite toujours un CréateurConcret.
● Si une famille de produits doit être étendue, non seulement l'interface, mais
aussi toutes les classes subordonnées du CréateurConcret doivent être
adaptées en conséquence.

Conclusion
Dans cette leçon nous avons présenté le patron Factory Method. Ce patron permet
de créer une instance à partir d'une classe dérivée d'un type abstrait. La classe
exacte utilisée pour produire l'objet n'est donc pas connue par l'appelant.
Le patron Factory Method se substitue ainsi au constructeur de classe habituel pour
détacher la création d’objets des objets eux-mêmes, permettant ainsi de suivre les
principes SOLID.

Factory Method est aussi connu sous le nom de constructeur virtuel.

Quels sont les principes dits SOLID ?

Les principes SOLID sont un sous-ensemble de principes de la programmation

orientée objet (POO) qui visent à améliorer le processus de développement des
logiciels orientés objet. L’acronyme "SOLID" désigne les cinq principes suivants :
● Principe de Single-Responsibility : Chaque classe ne devrait avoir qu'une
seule responsabilité.
● Principe de Open-Closed : Les unités logicielles doivent pouvoir être
étendues sans avoir à modifier leur comportement.
● Principe de Substitutions de Liskov : Une classe dérivée doit toujours être
utilisable à la place de sa classe de base.
● Principe de Interface-Segregation : Les interfaces doivent être parfaitement
adaptées aux besoins des clients qui y accèdent.
● Principe de Dependency-Inversion : Les classes à un niveau d’abstraction
supérieur ne devraient jamais dépendre de classes à un niveau d’abstraction
inférieur.