Factory Design Patterns Factory Method Plan Factory principes

Factory Design Patterns Factory Method

Plan • Factory : principes • The Factory Method pattern • The Abstract Factory pattern “Design patterns are recurring solutions to design problems you see over and over. ” [Smalltalk Companion] Factory Method Design Pattern

Intention Portée: classes • Définir une interface pour la création d’un objet, mais laisser les sous-classes décider de la classe à instancier • Une classe délègue l’instanciation à ses sousclasses. Factory Method Design Pattern

Motivation • PROBLEME: • Un framework possède • des classes abstraites par rapport aux applications • des sous-classes spécifiques aux applications pour réaliser différentes implémentations • SOLUTION: • Le Factory Method pattern • encapsule les connaissances sur quelles sous-classes il faut instancier • déplace ces connaissances à l’extérieur du framework Factory Method Design Pattern

Exemple I Factory Method Design Pattern

Exemple II • Enterprise Java. Bean (EJB) Application: • Un bean entité est une représentation objet de données persistentes ces données sont placées sur un support persistent, e. g. une base de données. • Une clé primaire identifie chaque instance d’un bean entité. • Les beans entités sont créés en instanciant un objet via une méthode factory (create). • Le même principe s’applique pour les beans de session. Factory Method Design Pattern

Exemple II (suite) import javax. naming. *; public class EJBClient { public static void main (String[] argv) { // get the JNDI naming context Context initial. Ctx = new Initial. Context (); // use the context to lookup the EJB Home interface Account. Home home=(Account. Home)initial. Ctx. lookup("Account"); // use the Home Interface to create a Session bean object Account account = home. create (10001, "Athul", 10000. 25 d); // invoke business methods account. credit (20000. 25 d); // remove the object account. remove (); } } Factory Method Design Pattern

Structure • Les sous-classes redéfinissent les méthodes abstraites de la classe abstraite pour rendre la sous-classe appropriée Factory Method Design Pattern

Collaboration • La classe Creator s’appuie sur ses sousclasses pour définir une méthode “factory” qui rend une instance de la classe appropriée Concrete. Product Factory Method Design Pattern

Quand l’appliquer? • Lorsque la classe qui doit instancier des classes ne connaît que les classes abstraites. • La classe ne connaît que le moment de la création d’un objet, • mais ne connaît pas quelle sorte d’objets, elle doit créer parce que cet objet dépend de l’application • Une classe veut que ses sous-classes spécifient quels objets seront créés • Les classes délèguent la responsabilité à une ou plusieurs sous-classes d’aide • on désire rendre locales connaissances qui vont aider à déterminer quel sera la classe d’aide dans une situation donnée Factory Method Design Pattern

Implémentations - Variations 1. __ • Une classe abstraite définit la méthode “factory” abstraite • • Alternative: une interface contient les signatures de création Les sous-classes de la classe abstraite implémentent l’interface 2. __ • Une classe concrète possède une implémentation par défaut de la méthode “factory” • Les sous-classes redéfinissent ou non la méthode “factory” 3. __ • La méthode “factory” possède un paramètre qui identifie la sorte d’objet à créer Factory Method Design Pattern

Factory Method: diagramme de classe I factory method Factory Method Design Pattern

Factory Method: diagramme de classe II factory method • Invocation de la factory method create. Document() qui est responsable de la construction des objets Factory Method Design Pattern

Bénéfices et désavantages I • Les méthodes “factory” éliminent le besoin de lier des classes spécifiques à une application dans le code • Le code n’intervient qu’avec l’interface du produit et peut ainsi travailler avec n’importe quelle classe concrète définie par l’usager • Les clients peuvent devoir sous-classer la classe Creator uniquement pour créer un type particulier d’objet Concrete. Product Factory Method Design Pattern

Bénéfices et désavantages II • Fournir des points d’arrimage (“hook”) pour les sous-classes • La création d’objets à l’intérieur d’une classe à l’aide d’une méthode “factory” est toujours plus flexible que la création directe de l’objet. Factory Method Design Pattern

Bénéfices et désavantages III • Connexion de hiérarchies parallèles • Les hiérarchies parallèles de classes surviennent lorsqu’une classe délègue une partie de ses responsabilités à une classe séparée Factory Method Design Pattern

Choix d’implémentation I • Deux variantes principales • La classe Creator est une classe abstraite et ne fournit pas d’implémentation par défaut de la méthode “factory” • La classe Creator est une classe concrète et fournit une implémentation par défaut de la méthode “factory” Factory Method Design Pattern

Choix d’implémentation II • La méthode “factory” est paramétrée. • Une variation sur ce patron permet à la méthode “factory” de créer plusieurs sortes de produits. • La méthode “factory” possède un paramètre qui identifie la sorte d’objet à créer. • Tous les objets créés par la méthode “factory” partagent l’interface Product. Factory Method Design Pattern

Factory Method: exemple II Classe abstraite interface Classe concrète public abstract class Tables. Creator {… public abstract Table. Code. Creator get. Table. Code. Creator(String db. Name) ; } public interface Table. Code. Creator {… void create. Source(); } public class DB 2 Table. Code. Creator implements Table. Code. Creator {… public void create. Source(padis. util. Class. Info. Descriptor descriptor, String working. Dir) { // CREATES JAVA SOURCE CODE FOR table. Name. java FILES} } public class Concrete. Tables. Creator extends Tables. Creator {… public Table. Code. Creator get. Table. Code. Creator(String db. Name) { if (db. Name. equals (“DB 2”)) return new DB 2 Table. Code. Creator(); else if (db. Name. equals (“ORACLE”)) return new ORACLETable. Code. Creator(); …} } Factory Method Design Pattern

exemple II (suite) [création des tables à partir d’un schéma XML] // Concrete. Tables. Creator String dbname = crs 4. util. Configuration. get. Instance(). get. Property(“default. database. name”); Table. Code. Creator code. Creator = this. get. Table. Code. Creator(dbname); //read from property for (int i=0; i<this. get. Classes. Array(). length; i++) { factory method code. Creator. create. Source( this. get. Classes. Array()[i], this. get. Working. Directory()); } Factory Method Design Pattern

Choix d’implémentation III • Conventions de noms (Naming conventions) • Bonne pratique d’utiliser des conventions de noms qui identifient clairement les méthodes “factory”. Factory Method Design Pattern

Références • E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns, Addison-Wesley Professional Computing Series, 1998. • J. W. Cooper, Java Design Patterns – A Tutorial, Addison. Wesley, 2000. • G. S. Raj, Factory Method creational pattern, http: //gsraj. tripod. com/design/creational/factory. html Factory Method Design Pattern