Factory Design Patterns Abstract Factory Plan Factory patterns

Factory Design Patterns Abstract Factory

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

Intention Portée: objets • Fournir une interface pour créer des familles d’objets reliés ou dépendants sans spécifier leur classe concrète Abstract Factory Design Pattern

Motivation • PROBLEME: • portabilité de l’application sur plusieurs plate-formes, • e. g. look and feel • l’instanciation de classes spécifiques à travers toute l’application rend plus difficile les changements ultérieurs de ces classes spécifiques • SOLUTION: • Le patron Abstract. Factory • • encapsule la responsabilité et le processus de création des produits isole les clients de l’implémentation Abstract Factory Design Pattern

Exemple Abstract Factory Design Pattern

Quand l’appliquer • Lorsqu’un système doit être indépendant de la manière dont ses objets sont créés, composés et représentés • Lorsqu’un système doit être configuré avec une famille d’objets parmi plusieurs familles d’objets reliés • Lorsqu’une famille d’objets est conçue pour être utilisée ensemble et que cette contrainte doit être renforcée • Pour fournir une librairie de classes de produits et pour ne révéler que leur interface et non leur implémentation Abstract Factory Design Pattern

Structure Seulement une collection de factory methods Abstract Factory Design Pattern

Participants • Abstract. Factory (Widget. Factory) • déclare une interface pour les opérations qui créent les produits abstraits. • Concrete. Factory (Motif. Widget. Factory, PMWidget. Factory) • Implémente les opérations pour créer les produits concrets. • Abstract. Product (Window, Scroll. Bar) • Déclare une interface pour un type de produit. • Concrete. Product (Motif. Window, Motif. Scroll. Bar) • Définit un produit à créer par la “factory” concrète correspondante. • Implémente l’interface Abstract. Product. • Client • N’utilise que les interfaces déclarées par les classes Abstract. Factory et Abstract. Product. Abstract Factory Design Pattern

Collaboration I • Il y a une classe “factory” abstraite qui déclare l’interface requise pour la création de chaque type d’objet • Pour chaque type spécifique d’objet, il existe • une classe abstraite (ou une interface) • des sous-classes concrètes qui spécialisent la classe abstraite pour leur contexte spécifique Abstract Factory Design Pattern

Collaboration II • Un client invoque les méthodes pour obtenir les instances, mais sans savoir les classes concrètes qui sont utilisées • Un client • crée les objets uniquement à l’aide de l’interface “factory” • ne possède pas de connaissances sur les classes qui implémentent les objets dans son cas particulier. Abstract Factory Design Pattern

Collaboration III • Toute instance unique de la classe Concrete. Factory est créée à l’exécution • Une sous-classe concrète de Abstract. Factory pour chaque famille de produit • Abstract. Factory délègue la création des produits à ses sous-classes (Concrete. Factory) Abstract Factory Design Pattern

Bénéfices et désavantages • Isole les classes concrètes • Isole les clients de l’implémentation, • les clients ne manipulent les instances qu’à travers leurs interfaces abstraites • Les noms des produits n’apparaissent pas dans le code du client • Facilite le changement et l’échange de familles de produits • Le support de nouveaux types de produits est difficile • Exige de spécialiser l’interface “factory”, ce qui implique des modifications équivalentes au niveau de la classe Abstract. Factory et de ses sous-classes Abstract Factory Design Pattern

Choix d’implémentation 1. 2. • • Nombre d’instances de “factory”. Une seule instance de Concrete. Factory (Singleton) par famille de produits Création des produits Utiliser des méthodes “factory” dans Abstract. Factory (abstraite ou concrète) pour chaque produit • • • 3. • Concrete. Factory va redéfinir ces méthodes Utiliser une sous-classe pour chaque famille de produits La sorte de produit est “encodée” dans la signature Alternative : utiliser des prototypes qui seront clonés Alternative : utiliser la réflexivité, i. e. Emmagasiner dans la factory les classes qui devront être instanciées “factories” extensibles pour identifier la sorte de produit à créer, on ajoute des paramètres aux opérations qui créent des objets Abstract Factory 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. • http: //www. brent. worden. org/tips/2002/abstr act. Factory. html Abstract Factory Design Pattern

Exemple supplémentaire • In the Java™ Message Service (JMS) Specification, • it is stated that accessing administered objects (queues, queue connection factories, topics, and topic connection factories) should be accomplished via JNDI lookup. • The specification recommends this approach • to allow JMS enabled systems to be vendor neutral • to allow these systems to use any JMS compliant implementation. • One way to isolate the accessing of administered objects is to use an abstract factory. • The abstract factory would define methods to create the four administered objects. • There would be one concrete factory that follows the recommendation in the JMS specification by using JNDI lookup. • Also, there could be one concrete factory and set of concrete products for each vendor variation of accessing administered object. • This way, clients access administered object through a vendor neutral abstract factory. • This allows for any JMS implementation to be used without affecting the client at all. • A sample Java™ implementation of this abstract factory is in JMS_Abstract. Factory. Example. zip. Abstract Factory Design Pattern