Simple Factory

L'idée centrale du modèle Factory est la séparation des créateurs et des

appelants il existe trois types : simple Factory, Factory Method et Abstract
Factory.
● Factory ou simple Factory : crée des objets sans exposer la logique
d'instanciation au client et fait référence à l'objet nouvellement créé
via une interface commune. c’est une version simplifiée de Factory
Method;
● Factory Method : définit une interface pour créer des objets, mais
laisse les sous-classes décider de la classe à instancier et fait
référence à l'objet nouvellement créé via une interface commune;
● Abstract Factory : offre l'interface pour créer une famille d'objets liés,
sans spécifier explicitement leurs classes.

Cette leçon présente le simple Factory en général, son intention et objectif,

le problème qu’il traite, la solution qu’il propose, sa structure et ses
avantages et inconvénients.

Les autres patrons de création (Factory Method, Abstract Factory, Builder

et Prototype) seront présentés de la même façon.

Nous illustrons à travers la figure ci-dessous chacun de ses patrons en

utilisant un exemple réel de création et configuration des téléphones et
Laptop de différentes marques issues de différentes usines.

Principe de base du patron Simple Factory

Notons que simple Factory n'est pas un patron de conception officiel.

Intention
Le patron Simple Factory représente le moyen le plus simple pour créer et
gérer des objets, car il encapsule simplement la création de différents
types d'objets en spécifiant l'objet à créer en passant son type à la fabrique.
Problème
Le patron Simple Factory vise à résoudre un problème fondamental lors de
l’instanciation (la création d’un objet concret d’une classe).

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

qui a besoin de cet objet est très rigide car la classe est liée à cet objet et la
modification de l'instanciation indépendamment de la classe est
impossible.
Solution
● Créer des objets au lieu de les instancier directement;
● Le simple factory évite le problème susmentionné 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 classe mentionné plus haut;
● Simple Factory est utilisé pour encapsuler la logique d'instanciation
des objets référencés via une interface commune. De nouvelles
classes peuvent être ajoutées avec des changements minimes.

Structure
Diagramme UML du patron Factory
Participants
● SimpleFactory implémente les opérations qui créent les objets
concrets;
● AbstractProduct déclare une interface pour un type d'objet;
● ConcreteProduct définit un objet qui doit être créé par la fabrique
concrète correspondante et implémente l'interface AbstractProduct.

Collaborations & implémentation

La classe SimpleFactory implémente le code pour instancier

ConcreteProduct1 et ConcreteProduct2. Lorsque le client a besoin d'un objet, il
appelle la méthode createProduct() de la SimpleFactory avec le paramètre
indiquant le type d'objet dont il a besoin.

SimpleFactory instancie le produit concret correspondant et le renvoie. Le

produit renvoyé est converti en type de classe de base afin que le client
gère n'importe quel produit de la même manière, qu'il s'agisse d'un
ConcreteProduct1 ou d'un ConcreteProduct2.
Exemple illustratif
Prenons l’exemple de production ou de création de téléphone mobiles afin
d’illustrer le simple factory, qui n’est pas vraiment un patron officiel mais
plutôt une façon plus simple de créer les objets sans utiliser new.
Commençons par la définition de l’interface Phone pour la spéfication
spécification standard de téléphone portable (AbstractProduct) :
public interface Phone { void make(); }

JavaCopy

Ensuite, définissons la classe Samsung pour la fabrication de telephone

mobile Samsung (Product1) :
public class Samsung implements Phone { public Samsung()
{ this.make(); } @Override public void
make() { System.out.println("make Samsung phone!"); }
}

JavaCopy

De la même façon, définissons la classe IPhone pour la fabrication de

telephone mobile de Apple (Product2) en implémentant l’interface Phone :
public class IPhone implements Phone { public IPhone() {
this.make(); } @Override public void make() {
System.out.println("make Apple phone!"); } }

JavaCopy

Enfin, on définie la classe PhoneFactory qui représente l’usine pour la

fabrication des téléphones :
public class PhoneFactory { public Phone makePhone(String
phoneType) { if(phoneType.equalsIgnoreCase("Samsung")){
return new Samsung(); } else
if(phoneType.equalsIgnoreCase("iPhone")) { return
new IPhone(); } return null; } }

JavaCopy

Dans le code client, examinons le cas d'utilisation suivant pour la création

des objets via des usines, pas directement par des new.
public class Client { public static void main(String[] arg)
{ PhoneFactory factory = new PhoneFactory();
Phone samsung = factory.makePhone("Samsung"); // make Samsung
phone! IPhone iPhone =
(IPhone)factory.makePhone("iPhone"); // make iphone! } }
JavaCopy

Conclusion : Lorsque nous voulons ajouter un autre téléphone mobile

Samsung, nous devons modifier la classe PhoneFactory (créer un téléphone
Samsung à nouveau). Par conséquent, nous pouvons utiliser Factory
Method pour optimiser la solution.

Diagramme UML du code ci-dessus

Remarque :

Une autre manière d'améliorer la souplesse est d'utiliser une usine de

fabrication d'usines (le mécanisme de création est lui-même paramétré).

Une usine peut aussi être utilisée comme un gestionnaire des objets
qu'elle a créé, et peut ainsi réaliser une méthode pour localiser un objet (en
renvoyant une référence pour cet objet), et pour détruire un objet à la
demande.

Usages connus
Ce patron est plus un idiome de programmation qu’un design pattern.
Rappel :
Le patron de conception propose une solution générale à un problème
récurrent dans la conception de logiciels tandis que l’idiome de
programmation propose une solution propre à un langage pour des détails
d'implémentation.

Il convient généralement à tous les logiciels dans lesquels de nouvelles

classes sont ajoutées de manière programmée et régulière, surtout si ces
classes doivent passer par le même processus de création.

Les systèmes d'authentification : dans le cas de factory simple, une classe

centrale va être utilisée avec divers paramètres qui varient en fonction de
l’autorisation de l’utilisateur.
Noter que cette solution n’est pas optimale car le processus
d’authentification peut être délégué à des classes Fabrique qui prennent
des décisions indépendantes concernant le traitement de l’utilisateur
respectif.

Avantages et inconvénients
Avantages
● C'est le moyen le plus simple de gérer la création d'objets en
spécifiant l'objet à créer en passant le type à la fabrique.

Inconvénients
● Nous devons modifier la classe Factory pour créer d’autres objets.
● Nous n’avons pas la possibilité de créer automatiquement des
familles d’objets et des combinaisons d’objets issues de plusieurs
types d'usines.

Conclusion
Cette leçon présente le patron Factory ou simple Factory qui gère la
création d’objet de la façon la plus simple, mais il ne permet pas de créer
des usines et des familles d’objets. Il permet donc de prendre en charge et
d’uniformiser l’instanciation de tous les objets d’une interface.

La solution pour le Factory en général est d’ utiliser deux patrons corrélés

Abstract Factory et Factory Method qui vont être abordés dans les leçons
qui suivent.

Abstract Factory qui définit une interface et une organisation génériques

pour la création d'objets ; la création est déléguée à des usines concrètes.
Abstract Factory peut être réalisé en utilisant Factory Method (une
méthode de création redéfinie dans une sous classe) qui permet à une
classe de reporter l'instanciation aux sous-classes.