1. Factory Design PatternsAbstract Factory

2. 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

3. 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

4. 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 AbstractFactory • encapsule la responsabilité et le processus de création des produits • isole les clients de l’implémentation Abstract Factory Design Pattern

5. Exemple Abstract Factory Design Pattern

6. 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

7. Seulement une collection de factory methods Structure Abstract Factory Design Pattern

8. Participants • AbstractFactory (WidgetFactory) • déclare une interface pour les opérations qui créent les produits abstraits. • ConcreteFactory (MotifWidgetFactory, PMWidgetFactory) • Implémente les opérations pour créer les produits concrets. • AbstractProduct (Window, ScrollBar) • Déclare une interface pour un type de produit. • ConcreteProduct (MotifWindow, MotifScrollBar) • Définit un produit à créer par la “factory” concrète correspondante. • Implémente l’interface AbstractProduct. • Client • N’utilise que les interfaces déclarées par les classes AbstractFactoryetAbstractProduct. Abstract Factory Design Pattern

9. 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

10. 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

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

12. 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 AbstractFactory et de ses sous-classes Abstract Factory Design Pattern

13. Choix d’implémentation • Nombre d’instances de “factory”. • Une seule instance de ConcreteFactory (Singleton) par famille de produits • Création des produits • Utiliser des méthodes “factory” dans AbstractFactory (abstraite ou concrète) pour chaque produit • ConcreteFactory 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

14. 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/abstractFactory.html Abstract Factory Design Pattern

15. 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_AbstractFactoryExample.zip. Abstract Factory Design Pattern