Modèle de méthode d’usine

Dans la programmation basée sur les classes , le modèle de méthode d’usine est un modèle de création qui utilise des méthodes d’usine pour traiter le problème de la création d’objets sans avoir à spécifier la classe exacte de l’objet qui sera créé. Cela se fait en créant des objets en appelant une méthode de fabrique – soit spécifiée dans une interface et implémentée par des classes enfants, soit implémentée dans une classe de base et éventuellement remplacée par des classes dérivées – plutôt qu’en appelant un constructeur .

Aperçu

Le modèle de conception de la méthode d’usine ^[1] est l’un des vingt-trois modèles de conception “Gang of Four” bien connus qui décrivent comment résoudre des problèmes de conception récurrents pour concevoir des logiciels orientés objet flexibles et réutilisables, c’est-à-dire des objets plus faciles à utiliser. mettre en œuvre, modifier, tester et réutiliser.

Le modèle de conception de la méthode d’usine résout des problèmes tels que : ^[2]

• Comment créer un objet pour que les sous-classes puissent redéfinir quelle classe instancier ?
• Comment une classe peut-elle différer l’instanciation aux sous-classes ?

Le modèle de conception de la méthode d’usine décrit comment résoudre ces problèmes :

• Définissez une opération distincte ( méthode de fabrique ) pour créer un objet.
• Créez un objet en appelant une méthode de fabrique .

Cela permet d’écrire des sous-classes pour changer la façon dont un objet est créé (pour redéfinir quelle classe instancier).
Voir aussi le diagramme de classes UML ci-dessous.

Définition

“Définissez une interface pour créer un objet, mais laissez les sous-classes décider quelle classe instancier. La méthode Factory permet à une classe de différer l’instanciation qu’elle utilise aux sous-classes.” ( Gang des quatre )

La création d’un objet nécessite souvent des processus complexes qu’il n’est pas approprié d’inclure dans un objet composant. La création de l’objet peut conduire à une duplication importante de code, peut nécessiter des informations non accessibles à l’objet composant, peut ne pas fournir un niveau d’abstraction suffisant, ou peut ne pas faire partie des préoccupations de l’objet composant . Le modèle de conception de méthode d’usine gère ces problèmes en définissant une méthode distincte pour créer les objets, que les sous- classes peuvent ensuite remplacer pour spécifier le type dérivé de produit qui sera créé.

Le modèle de méthode de fabrique repose sur l’héritage, car la création d’objets est déléguée à des sous-classes qui implémentent la méthode de fabrique pour créer des objets. ^[3]

Structure

Diagramme de classes UML

Un exemple de diagramme de classes UML pour le modèle de conception Factory Method. ^[4]

Dans le diagramme de classes UML ci-dessus , la classe qui requiert un objet n’instancie pas la classe directement. Au lieu de cela, le fait référence à un séparé pour créer un objet produit, ce qui rend le indépendant de la classe concrète instanciée. Les sous-classes de peuvent redéfinir la classe à instancier. Dans cet exemple, la sous- classe implémente l’abstrait en instanciant la classe.CreatorProductProduct1CreatorfactoryMethod()CreatorCreatorCreator1factoryMethod()Product1

Exemple

Un jeu de labyrinthe peut être joué en deux modes, l’un avec des salles régulières qui ne sont connectées qu’avec des salles adjacentes, et l’autre avec des salles magiques qui permettent aux joueurs d’être transportés au hasard.

Structure

Roomest la classe de base d’un produit final ( MagicRoomou OrdinaryRoom). MazeGamedéclare la méthode d’usine abstraite pour produire un tel produit de base. MagicRoomet OrdinaryRoomsont des sous-classes du produit de base mettant en œuvre le produit final. MagicMazeGameet OrdinaryMazeGamesont des sous-classes de MazeGamemise en œuvre de la méthode d’usine produisant les produits finaux. Ainsi, les méthodes de fabrique découplent les appelants ( MazeGame) de l’implémentation des classes concrètes. Cela rend le “nouvel” Opérateur redondant, permet le respect du Principe ouvert/fermé et rend le produit final plus flexible en cas de changement.

Exemples d’implémentations

C# // Vocabulaire vide de l’ interface publique de l’objet réel IPerson { string GetName (); } public class Villageois : IPerson { public string GetName () { return “Village Person” ; } } public class CityPerson : IPerson { public string GetName () { return “City Person” ; } } public enum PersonType { Rural , Urbain } /// <summary> /// Implémentation de Factory – Utilisé pour créer des objets. /// </summary> public class Factory { public IPerson GetPerson ( PersonType type ) { switch ( type ) { case PersonType . Rural : renvoie un nouveau Villageois (); cas PersonType . Urban : retourne new CityPerson (); par défaut : lance une nouvelle exception NotSupportedException (); } } }

Dans le code ci-dessus, vous pouvez voir la création d’une interface appelée IPersonet de deux implémentations appelées Villageret CityPerson. En fonction du type passé à l’ Factoryobjet, nous renvoyons l’objet concret d’origine en tant qu’interface IPerson.

Une méthode de fabrique n’est qu’un ajout à une Factoryclasse. Il crée l’objet de la classe via des interfaces mais d’un autre côté, il laisse également la sous-classe décider quelle classe est instanciée.

interface publique IProduct { chaîne GetName (); bool SetPrice ( prix double ); } Téléphone de la classe publique : IProduct { private double _price ; public string GetName () { return “Apple TouchPad” ; } public bool SetPrice ( prix double ) { _price = prix ; retourne vrai ; } } /* Presque identique à Factory, juste une exposition supplémentaire pour faire quelque chose avec la méthode créée */ public abstract class ProductAbstractFactory { protected abstract IProduct MakeProduct (); public IProduct GetObject () // Implémentation de la méthode Factory. { renvoie ceci . MarqueProduit (); } } public class PhoneConcreteFactory : ProductAbstractFactory { protected override IProduct MakeProduct () { IProduct product = new Phone (); // Faites quelque chose avec l’objet après avoir obtenu l’objet. produit . DéfinirPrix ( 20.30 ); retourner le produit ; } }

Vous pouvez voir que nous avons utilisé MakeProductdans concreteFactory. En conséquence, vous pouvez facilement appeler MakeProduct()à partir de celui-ci pour obtenir le IProduct. Vous pouvez également écrire votre logique personnalisée après avoir obtenu l’objet dans la méthode Factory concrète. Le GetObject est rendu abstrait dans l’interface Factory.

Java

Cet exemple Java est similaire à celui du livre Design Patterns .

Le MazeGame utilise des salles mais il confie la responsabilité de créer des salles à ses sous-classes qui créent les classes concrètes. Le mode de jeu normal pourrait utiliser cette méthode de modèle :

public abstract class Room { abstract void connect ( Room room ); } public class MagicRoom étend Room { public void connect ( Room room ) {} } public class OrdinaryRoom étend Room { public void connect ( Room room ) {} } public abstract class MazeGame { private final List < Room > rooms = new ArrayList <> (); public MazeGame () { Pièce room1 = makeRoom (); Pièce room2 = makeRoom (); chambre1 . connecter ( pièce2 ); chambres . ajouter ( pièce1 ); chambres . ajouter ( pièce2 ); } pièce protégée abstraite makeRoom (); }

Dans l’extrait ci-dessus, le MazeGameconstructeur est une méthode de modèle qui crée une logique commune. Il fait référence à la makeRoomméthode d’usine qui encapsule la création de pièces de sorte que d’autres pièces puissent être utilisées dans une sous-classe. Pour implémenter l’autre mode de jeu qui possède des salles magiques, il suffit de surcharger la makeRoomméthode :

public class MagicMazeGame étend MazeGame { @Override protected Room makeRoom () { return new MagicRoom (); } } public class OrdinaryMazeGame étend MazeGame { @Override protected Room makeRoom () { return new OrdinaryRoom (); } } MazeGame JeuOrdinaire = new OrdinaryMazeGame ( ); MazeGame magicGame = new MagicMazeGame (); PHP

Un autre exemple en PHP suit, cette fois en utilisant des implémentations d’interface par opposition à la sous-classe (cependant, la même chose peut être obtenue grâce à la sous-classe). Il est important de noter que la méthode factory peut également être définie comme publique et appelée directement par le code client (contrairement à l’exemple Java ci-dessus).

/* Interfaces usine et voiture */ interface CarFactory { public function makeCar () : Car ; } interface Car { public function getType () : string ; } /* Réalisations concrètes de l’usine et de la voiture */ class SedanFactory implémente CarFactory { public function makeCar () : Car { return new Sedan (); } } class Sedan implémente Car { public function getType () : string { return ‘Sedan’ ; } } /* Client */ $factory = new SedanFactory (); $voiture = $usine -> makeCar (); print $car -> getType (); Python

Identique à l’exemple Java.

de abc import ABC , abstractmethod class MazeGame ( ABC ): def __init__ ( self ) -> None : self . chambres = [] soi . _prepare_rooms () def _prepare_rooms ( self ) -> Aucun : room1 = self . make_room () room2 = self . make_room () chambre1 . connecter ( pièce2 ) soi . chambres . ajouter ( room1 ) soi . chambres . ajouter ( room2 ) def play ( self ) -> None : print ( ‘Playing using ” {} “‘ . format ( self . rooms [ 0 ])) @abstractmethod def make_room ( self ): raise NotImplementedError ( “Vous devriez implémenter ceci!” ) class MagicMazeGame ( MazeGame ): def make_room ( self ): return MagicRoom () class OrdinaryMazeGame ( MazeGame ): def make_room ( self ): return OrdinaryRoom () class Room ( ABC ): def __init__ ( self ) -> None : self . chambres_connectées = [] def connect ( self , room ) -> None : self . chambres_connectées . ajouter ( pièce ) class MagicRoom ( Room ): def __str__ ( self ): return “Magic room” class OrdinaryRoom ( Room ): def __str__ ( self ): return “Ordinary room” JeuOrdinaire = JeuMazeOrdinaire () JeuOrdinaire . jouer () magicGame = MagicMazeGame () magicGame . jouer ()

Les usages

• Dans ADO.NET , IDbCommand.CreateParameter est un exemple d’utilisation de la méthode de fabrique pour connecter des hiérarchies de classes parallèles.
• Dans Qt , QMainWindow::createPopupMenu est une méthode de fabrique déclarée dans un framework qui peut être surchargée dans le code de l’application .
• En Java , plusieurs fabriques sont utilisées dans le package javax.xml.parsers . par exemple javax.xml.parsers.DocumentBuilderFactory ou javax.xml.parsers.SAXParserFactory.
• Dans l’ API DOM HTML5 , l’interface Document contient une méthode de fabrique createElement pour créer des éléments spécifiques de l’interface HTMLElement.

Voir également

• Design Patterns , le livre très influent
• Patron de conception , aperçu des patrons de conception en général
• Modèle d’usine abstrait , un modèle souvent mis en œuvre à l’aide de méthodes d’usine
• Modèle de constructeur , un autre modèle de création
• Modèle de méthode modèle , qui peut appeler des méthodes d’usine
• L’idée de Joshua Bloch d’une méthode d’usine statique , qui, selon lui, n’a pas d’équivalent direct dans les Design Patterns .

Références

1. ^ Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1994). Modèles de conception : éléments de logiciels réutilisables orientés objet . Addison Wesley. pp. 107ff. ISBN 0-201-63361-2.{{cite book}}: Maint CS1 : noms multiples : liste des auteurs ( lien )
2. ^ “Le modèle de conception de la méthode d’usine – problème, solution et applicabilité” . w3sDesign.com . Récupéré le 17/08/2017 .
3. ^ Freeman, Éric; Freeman, Élisabeth; Kathy, Sierra; Bert, Bates (2004). Hendrickson, Mike; Loukides, Mike (éd.). Head First Design Patterns (livre de poche) . Vol. 1. O’REILLY. p. 162. ISBN 978-0-596-00712-6. Récupéré le 12/09/2012 .
4. ^ “Le modèle de conception de la méthode d’usine – Structure et collaboration” . w3sDesign.com . Récupéré le 12/08/2017 .

• Martin Fowler ; Kent Beck ; John Brent ; Guillaume Opdyke ; Don Roberts (juin 1999). Refactoring : amélioration de la conception du code existant . Addison-Wesley. ISBN 0-201-48567-2.
• Gamma, Érich ; Helm, Richard ; Johnson, Ralph; Vlissides, John (1994). Modèles de conception : éléments de logiciels réutilisables orientés objet . Addison-Wesley. ISBN 0-201-63361-2.
• Cox, Brad J. (1986). Programmation orientée objet : une approche évolutive . Addison-Wesley. ISBN 978-0-201-10393-9.
• Cohen, Tal; Gil, Joseph (2007). “Une meilleure construction avec des usines” (PDF) . Journal de la technologie des objets . Bertrand Meyer . 6 (6): 103. doi : 10.5381/jot.2007.6.6.a3 . Récupéré le 12/03/2007 .

Liens externes

Le Wikibook Computer Science Design Patterns a une page sur le sujet : Exemples de méthodes d’usine

• Implémentation du modèle de conception d’usine en Java
• Méthode d’usine en UML et en LePUS3 (un langage de description de conception)
• Considérez les méthodes d’usine statiques par Joshua Bloch