Le document décrit le patron de conception Factory Method. Ce patron permet à une classe de déléguer l'instanciation d'objets à des sous-classes, tout en gardant le contrôle sur le choix de la classe à instancier.
0 évaluation0% ont trouvé ce document utile (0 vote)
76 vues7 pages
Le document décrit le patron de conception Factory Method. Ce patron permet à une classe de déléguer l'instanciation d'objets à des sous-classes, tout en gardant le contrôle sur le choix de la classe à instancier.
Le document décrit le patron de conception Factory Method. Ce patron permet à une classe de déléguer l'instanciation d'objets à des sous-classes, tout en gardant le contrôle sur le choix de la classe à instancier.
Le document décrit le patron de conception Factory Method. Ce patron permet à une classe de déléguer l'instanciation d'objets à des sous-classes, tout en gardant le contrôle sur le choix de la classe à instancier.
Téléchargez comme PDF, TXT ou lisez en ligne sur Scribd
Télécharger au format pdf ou txt
Vous êtes sur la page 1/ 7
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.
