Factory Design Patterns Abstract Factory

Abstract Factory Design Pattern Plan Factory patterns: principesFactory patterns: principes The Factory Method patternThe Factory Method pattern The Abstract Factory patternThe 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 Portée: objets Fournir une interface pour créer des familles d’objets reliés ou dépendants sans spécifier leur classe concrèteFournir 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:PROBLEME: portabilité de l’application sur plusieurs plate-formes,portabilité de l’application sur plusieurs plate-formes, e.g. look and feele.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écifiquesl’instanciation de classes spécifiques à travers toute l’application rend plus difficile les changements ultérieurs de ces classes spécifiques SOLUTION:SOLUTION: Le patron AbstractFactoryLe patron AbstractFactory encapsule la responsabilité et le processus de création des produitsencapsule la responsabilité et le processus de création des produits isole les clients de l’implémentationisole les clients de l’implémentation

Abstract Factory Design Pattern Exemple

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ésLorsqu’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ésLorsqu’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éeLorsqu’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émentationPour 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 AbstractFactory ( WidgetFactory )AbstractFactory ( WidgetFactory ) déclare une interface pour les opérations qui créent les produits abstraits.déclare une interface pour les opérations qui créent les produits abstraits. ConcreteFactory ( MotifWidgetFactory, PMWidgetFactory )ConcreteFactory ( MotifWidgetFactory, PMWidgetFactory ) Implémente les opérations pour créer les produits concrets.Implémente les opérations pour créer les produits concrets. AbstractProduct ( Window, ScrollBar )AbstractProduct ( Window, ScrollBar ) Déclare une interface pour un type de produit.Déclare une interface pour un type de produit. ConcreteProduct ( MotifWindow, MotifScrollBar )ConcreteProduct ( MotifWindow, MotifScrollBar ) Définit un produit à créer par la “factory” concrète correspondante.Définit un produit à créer par la “factory” concrète correspondante. Implémente l’interface AbstractProduct.Implémente l’interface AbstractProduct. ClientClient N’utilise que les interfaces déclarées par les classes AbstractFactory et AbstractProduct.N’utilise que les interfaces déclarées par les classes AbstractFactory et AbstractProduct.

Abstract Factory Design Pattern Collaboration I Il y a une classe “factory” abstraiteIl 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,Pour chaque type spécifique d’objet, il existe une classe abstraite (ou une interface)une classe abstraite (ou une interface) des sous-classes concrètes qui spécialisent la classe abstraite pour leur contexte spécifiquedes 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,Un client invoque les méthodes pour obtenir les instances, mais sans savoir les classes concrètes qui sont utilisées Un clientUn client crée les objets uniquement à l’aide de l’interface “factory”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.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 ConcreteFactory est créée à l’exécutionToute instance unique de la classe ConcreteFactory est créée à l’exécution Une sous-classe concrète de AbstractFactoryUne sous-classe concrète de AbstractFactory pour chaque famille de produit AbstractFactory délègue la création des produitsAbstractFactory délègue la création des produits à ses sous-classes ( ConcreteFactory )

Abstract Factory Design Pattern Bénéfices et désavantages Isole les classes concrètesIsole les classes concrètes Isole les clients de l’implémentation,Isole les clients de l’implémentation, les clients ne manipulent les instances qu’à travers leurs interfaces abstraitesles clients ne manipulent les instances qu’à travers leurs interfaces abstraites Les noms des produits n’apparaissent pas dans le code du clientLes noms des produits n’apparaissent pas dans le code du client Facilite le changement et l’échange de familles de produitsFacilite le changement et l’échange de familles de produits Le support de nouveaux types de produits est difficileLe 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-classesExige 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 Choix d’implémentation 1.Nombre d’instances de “factory”. Une seule instance de ConcreteFactory (Singleton) par famille de produitsUne seule instance de ConcreteFactory (Singleton) par famille de produits 2.Création des produits Utiliser des méthodes “factory” dans AbstractFactory (abstraite ou concrète) pour chaque produitUtiliser des méthodes “factory” dans AbstractFactory (abstraite ou concrète) pour chaque produit ConcreteFactory va redéfinir ces méthodesConcreteFactory va redéfinir ces méthodes Utiliser une sous-classe pour chaque famille de produitsUtiliser une sous-classe pour chaque famille de produits La sorte de produit est “encodée” dans la signatureLa sorte de produit est “encodée” dans la signature Alternative : utiliser des prototypes qui seront clonésAlternative : utiliser des prototypes qui seront clonés Alternative : utiliser la réflexivité,Alternative : utiliser la réflexivité, i.e. Emmagasiner dans la factory les classes qui devront être instanciées 3.“factories” extensibles pour identifier la sorte de produit à créer, on ajoute des paramètres aux opérations qui créent des objetspour 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.E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns, Addison-Wesley Professional Computing Series, J.W. Cooper, Java Design Patterns – A Tutorial, Addison-Wesley, 2000.J.W. Cooper, Java Design Patterns – A Tutorial, Addison-Wesley, actFactory.htmlhttp:// actFactory.html

Abstract Factory Design Pattern Exemple supplémentaire In the Java™ Message Service (JMS) Specification,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.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 approachThe specification recommends this approach to allow JMS enabled systems to be vendor neutralto allow JMS enabled systems to be vendor neutral to allow these systems to use any JMS compliant implementation.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.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.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.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. 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 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.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.A sample Java™ implementation of this abstract factory is in JMS_AbstractFactoryExample.zip.