Quelle est la différence fondamentale entre les modèles de conception Factory et Abstract Factory?
Quelle est la différence fondamentale entre les modèles Factory et Abstract Factory?
Avec le modèle Factory, vous produisez des instances d'implémentations (Apple, Banana, Cherry, etc.) d'une interface particulière - par exemple, IFruit.
Avec le motif Abstract Factory, vous offrez à quiconque le moyen de créer sa propre usine. Cela permet à votre entrepôt d’être soit un IFruitFactory, soit un IJuiceFactory, sans que votre entrepôt n’ait besoin d’être au courant des fruits ou des jus de fruits.
Source pour cette information tirée de: http://Java.dzone.com/news/intro-design-patterns-abstract
Méthode abstraite vs usine
Les méthodes d'une fabrique abstraite sont implémentées en tant que méthodes d'usine. Le modèle de fabrique abstraite et le modèle de méthode fabrique découplent le système client des classes d'implémentation réelles via les types abstraits et les fabriques. La méthode Factory crée des objets par héritage, où Abstract Factory crée des objets par la composition.
Le modèle de fabrique abstraite se compose des éléments AbstractFactory, ConcreteFactory, AbstractProduct, ConcreteProduct et Client.
Comment mettre en œuvre
Le motif abstrait d'usine peut être mis en œuvre à l'aide du motif de méthode d'usine, du motif prototype ou du motif singleton. L'objet ConcreteFactory peut être implémenté en tant que Singleton, car une seule instance de l'objet ConcreteFactory est nécessaire.
Le modèle Factory Method est une version simplifiée du modèle Abstract Factory. Le modèle Factory Method est chargé de créer des produits appartenant à une famille, tandis que le modèle Abstract Factory traite plusieurs familles de produits.
Méthode Factory utilise des interfaces et des classes abstraites pour découpler le client de la classe du générateur et des produits résultants. Abstract Factory possède un générateur qui contient plusieurs méthodes d’usine, ainsi que des interfaces permettant de découpler le client du générateur et des produits.
Quand utiliser le modèle de méthode d'usine
Utilisez le modèle de méthode d'usine lorsqu'il est nécessaire de découpler un client d'un produit particulier utilisé. Utilisez la méthode d'usine pour décharger un client de la création et de la configuration des instances d'un produit.
Quand utiliser le motif abstrait d'usine
Utilisez le modèle Fabrique abstraite lorsque les clients doivent être découplés des classes de produits. Particulièrement utile pour la configuration et la modification du programme. Le modèle Abstract Factory peut également imposer des contraintes sur les classes à utiliser avec d'autres. La construction de nouvelles usines de béton peut nécessiter beaucoup de travail.
Exemples:
Abstract Factory Exemple 1
Cette spécification pour les disques permettant de préparer différents types de pâtes dans un fabricant de pâtes est l’abstrait Factory et chaque disque spécifique est une Factory. toutes les usines (disques de fabrication de pâtes) héritent de leurs propriétés de l'usine abstraite. Chaque disque contient des informations sur la manière de créer les pâtes, contrairement au fabricant de pâtes.
Abstract Factory Exemple 2:
L'équipement d'estampage correspond à l'usine abstraite, car il s'agit d'une interface pour les opérations qui créent des objets produits abstraits. Les matrices correspondent à l'usine de béton, car elles créent un produit en béton. Chaque catégorie de pièce (capot, porte, etc.) correspond au produit abstrait. Des pièces spécifiques (c'est-à-dire la porte côté conducteur pour 99 camry) correspondent aux produits en béton.
Exemple de méthode d'usine:
L'entreprise de jouets correspond au créateur, car elle peut utiliser l'usine pour créer des objets de produit. La division de la société de jouets qui fabrique un type spécifique de jouet (cheval ou voiture) correspond au ConcreteCreator.
Modèle d'usine: l'usine produit des implémentations IProduct
Modèle d'usine abstrait: Une usine-usine produit des IFactories, qui à leur tour produisent des produits IP :)
[Mise à jour en fonction des commentaires]
Ce que j’ai écrit plus tôt n’est pas correct selon Wikipedia au moins. Une fabrique abstraite est simplement une interface de fabrique. Avec celui-ci, vous pouvez changer vos usines au moment de l'exécution pour autoriser différentes usines dans différents contextes. Des exemples peuvent être différentes usines pour différents systèmes d’exploitation, fournisseurs SQL, pilotes de middleware, etc.
Le modèle d'usine abstraite
Fournissez une interface pour créer des familles d'objets liés ou dépendants sans spécifier leurs classes concrètes.
Le modèle Abstract Factory est très similaire au modèle Factory Method. Une différence entre les deux réside dans le fait qu’avec le motif Abstract Factory, une classe délègue la responsabilité de l’instanciation d’objet à un autre objet via la composition, tandis que le motif Factory Method utilise l’héritage et repose sur une sous-classe pour gérer l’instanciation d’objet souhaitée.
En réalité, l’objet délégué utilise fréquemment les méthodes de fabrication pour effectuer l’instanciation!
Modèle d'usine
Les modèles d'usine sont des exemples de modèles de création
Les modèles de création abstraite le processus d'instanciation d'objet. Ils cachent la manière dont les objets sont créés et aident à rendre le système global indépendant de la manière dont ses objets sont créés et composés.
Les modèles de création de classe se concentrent sur l'utilisation de l'héritage pour décider de l'objet à instancier. Méthode d'usine
Les modèles de création d'objet se concentrent sur la délégation de l'instanciation à un autre objet. Abstract Factory
Référence: Factory vs Abstract Factory
Méthode Factory: Vous avez une usine qui crée des objets dérivés d'une classe de base particulière
Fabrique abstraite: Vous avez une fabrique qui crée d'autres fabriques et ces fabriques créent à leur tour des objets dérivés des classes de base. Vous faites cela parce que vous ne voulez souvent pas simplement créer un seul objet (comme avec la méthode Factory) - vous voulez plutôt créer une collection d'objets liés.
La fabrique abstraite est une interface permettant de créer des objets liés, mais la méthode de la fabrique est une méthode. La fabrique abstraite est mise en œuvre par la méthode de la fabrique.
Différence de base:
Usine: Crée des objets sans exposer la logique d'instanciation au client.
Méthode Factory : définit une interface pour la création d'un objet, mais laisse les sous-classes décider de la classe à instancier. . La méthode Factory permet à une classe de différer l'instanciation en sous-classes
Fabrique abstraite : fournit une interface pour la création de familles d'objets liés ou dépendants sans spécifier leurs classes concrètes.
AbstractFactory pattern utilise la composition pour déléguer la responsabilité de la création d'un objet à une autre classe, tandis que , méthode Factory utilise l'héritage et repose sur la classe ou la sous-classe dérivée. classe pour créer un objet
De oodesign articles:
Usine diagramme de classes:
Exemple: StaticFactory
public class ShapeFactory {
//use getShape method to get object of type shape
public static Shape getShape(String shapeType){
if(shapeType == null){
return null;
}
if(shapeType.equalsIgnoreCase("CIRCLE")){
return new Circle();
} else if(shapeType.equalsIgnoreCase("RECTANGLE")){
return new Rectangle();
} else if(shapeType.equalsIgnoreCase("SQUARE")){
return new Square();
}
return null;
}
}
L'exemple FactoryMethod mettant en œuvre Factory non statique est disponible dans cet article:
Modèles de conception: méthode vs usine vs usine abstraite
Quand utiliser: Le client a simplement besoin d'une classe et ne se soucie pas de l'implémentation concrète qu'il obtient.
Méthode d'usine classe digaram:
Quand utiliser: Le client ne sait pas quelles classes concrètes il devra créer au moment de l'exécution, mais il veut juste obtenir une classe qui fera le emploi.
Fabrique abstraite diagramme de classes de dzone
Quand utiliser: Lorsque votre système doit créer plusieurs familles de produits ou que vous souhaitez fournir une bibliothèque de produits sans exposer les détails de la mise en œuvre.
Les exemples de code source dans les articles ci-dessus sont très utiles pour comprendre les concepts clairement.
Question SE associée avec exemple de code:
Modèle d'usine. Quand utiliser les méthodes d'usine?
Différences:
- Les classes Abstract Factory sont souvent implémentées avec les méthodes Factory, mais elles peuvent également être implémentées avec Prototype
- Les conceptions commencent par utiliser la méthode d'usine (moins de complications, plus de possibilités de personnalisation, les sous-classes prolifèrent) et évoluent vers d'autres modèles de création (plus souples, plus complexes) nécessitant davantage de flexibilité.
- Les méthodes d'usine sont généralement appelées dans les méthodes de modèle.
Autres articles utiles:
factory_method de la source
abstract_factory de la source
abstract-factory-design-pattern de journaldev
Exemple/Scénario pour Abstract Factory
Je vis dans un endroit où il pleut pendant la saison des pluies, il neige en hiver et il fait chaud et ensoleillé en été. J'ai besoin de différents types de vêtements pour me protéger des éléments. Pour ce faire, je vais au magasin près de chez moi et demande des vêtements/objets pour me protéger. Le commerçant me donne l'article approprié selon l'environnement et la profondeur de ma poche. Les articles qu'il me donne sont du même niveau de qualité et de prix. Comme il est conscient de mes principes, il est facile pour lui de le faire. Mais lorsqu'un homme riche de l'autre côté de la rue présente les mêmes exigences, il obtient un article de marque coûteux. Une chose remarquable est que tous les éléments qu'il me donne se complètent en termes de qualité, de qualité et de coût. On peut dire qu'ils vont ensemble. Il en va de même pour les objets que ce riche possède.
Donc, en regardant le scénario ci-dessus, j'apprécie maintenant l'efficacité du commerçant. Je peux remplacer ce commerçant par un magasin de résumés. Les éléments que nous obtenons avec les éléments abstraits et moi et les riches en tant que clients potentiels. Tout ce dont nous avons besoin est le produit/article qui convient à nos besoins.
Maintenant, je peux facilement me voir envisager de créer une boutique en ligne offrant un ensemble de services à ses nombreux clients. Chaque client appartient à l'un des trois groupes. Lorsqu'un utilisateur du groupe premium ouvre le site, il obtient une excellente interface utilisateur, un panneau d'annonces hautement personnalisé, davantage d'options dans les menus, etc. et légèrement moins egronomic UI. Enfin, c’est mon genre d’utilisateur, un utilisateur du "groupe libre". Je suis juste assez servi pour que je ne sois pas offensé. L'interface utilisateur est un strict minimum, les publicités sont tellement éloignées de la réalité que je ne sais pas ce qui les contient, enfin le menu n'a plus qu'à se déconnecter.
Si je pouvais construire quelque chose comme ce site Web, je prendrais au sérieux Abstract Factory Pattern.
Produits abstraits: volet de publicité, menu, UI Painter.
Abstract Factory: Expérience utilisateur Web Store
Concreate Factory: Expérience utilisateur Premium, Expérience utilisateur Gold, Expérience utilisateur générale.
Beaucoup de gens se sentiront peut-être surpris, mais cette question est incorrecte . Si vous entendez cette question lors d'une interview, vous devez aider l'intervieweur à comprendre où se trouve la confusion.
Commençons par le fait qu’il n’existe pas de modèle concret appelé "usine". Il y a un motif appelé "Fabrique abstraite" et un motif appelé "Méthode d'usine".
Alors, que veut dire "Usine"? un des éléments suivants (tous peuvent être considérés comme corrects, en fonction de la portée de la référence):
- Certaines personnes l'utilisent comme alias (raccourci) pour " Abstract Factory ".
- Certaines personnes l'utilisent comme alias (raccourci) pour " Méthode d'usine ".
- Certaines personnes l’utilisent comme nom plus général pour tous les modèles d’usine/de création. Par exemple. "Abstract Factory" et "Factory Method" sont des usines.
Et, malheureusement , beaucoup de gens utilisent "Usine" pour désigner un autre type d’usine, qui crée une ou plusieurs usines (ou leurs interfaces). Basé sur leur théorie:
Product implémente IProduct, qui est créé par Factory, qui implémente IFactory, qui est créé par AbstractFactory.
Pour comprendre à quel point c'est idiot, poursuivons notre équation:
AbstractFactory implémente IAbstractFactory, qui est créé par ... AbstractAbstractFactory ???
J'espère que vous voyez le point. Ne vous trompez pas et n'inventez pas des choses qui n'existent pas pour la raison.
-
P.S : Factory pour les produits est AbstractFactory et Factory pour les usines abstraites n'est qu'un autre exemple de AbstractFactory.
//Abstract factory - Provides interface to create factory of related products
interface PizzaIngredientsFactory{
public Dough createDough(); //Will return you family of Dough
public Clam createClam(); //Will return you family of Clam
public Sauce createSauce(); //Will return you family of Sauce
}
class NYPizzaIngredientsFactory implements PizzaIngredientsFactory{
@Override
public Dough createDough(){
//create the concrete dough instance that NY uses
return doughInstance;
}
//override other methods
}
Les définitions du manuel sont déjà fournies par d'autres réponses. Je pensais en donner un exemple également.
Donc ici la PizzaIngredientsFactory est une fabrique abstraite car elle fournit des méthodes pour créer une famille de produits connexes.
Notez que chaque méthode de la fabrique abstraite est une méthode fabrique en elle-même. Like createDough() est en soi une méthode fabrique dont les implémentations concrètes seront fournies par des sous-classes telles que NYPizzaIngredientsFactory. Ainsi, chaque emplacement différent peut créer des exemples d'ingrédients concrets appartenant à leur emplacement.
Méthode d'usine
Fournit un exemple de mise en œuvre concrète
Dans l'exemple:
- createDough() - fournit une implémentation concrète pour la pâte. C'est donc une méthode d'usine
Usine abstraite
Fournit une interface pour créer une famille d'objets liés
Dans l'exemple:
- PizzaIngredientsFactory est une fabrique abstraite, car elle permet de créer un ensemble d'objets connexes tels que Dough, Clams, Sauce. Pour créer chaque famille d'objets, il fournit une méthode d'usine.
Exemple de modèles de conception Head First
J'ai quelques points à contribuer avec la réponse de John comme suit:
Abstract Factory est une usine d'usines!
Avec "Factory Method" (parce que "Factory" est ambigu), vous produisez des implémentations (Lemon, Orange, etc.) d'une interface particulière - disons IFruit. Cette usine pourrait s'appeler CitricFruitFactory.
Mais maintenant, vous voulez créer un autre type de fruit que CitricFruitFactory ne peut pas créer. Peut-être que le code de CitricFruitFactory n'aurait pas de sens si vous créez un Strawberry (la fraise n'est pas un fruit citrique!).
Vous pouvez donc créer une nouvelle usine appelée RedFruitFactory produisant Strawberry, Raspberry, etc.
Comme John Feminella a dit: "Avec le motif Abstract Factory, vous produisez des implémentations d’une interface Factory particulière - par exemple, IFruitFactory. Chacun de ceux-ci sait comment créer différentes sortes de fruits. "
Les implémentations de IFruitFactory sont CitricFruitFactory et RedFruitFactory!
Mes sources sont: StackOverflow, tutorialspoint.com, programmers.stackexchange.com et CodeProject.com.
Factory Method (également appelé Factory) sert à découpler le client d'une implémentation Interface. Par exemple, nous avons une interface Shape avec deux implémentations Circle et Square. Nous avons défini une classe de fabrique avec une méthode de fabrique avec un paramètre de détermination tel que Type et une nouvelle implémentation associée de l'interface Shape.
Abstract Factory contient plusieurs méthodes d'usine ou une interface d'usine par plusieurs implémentations d'usine. Pour l'exemple ci-dessus, nous avons une interface Color avec deux implémentations Red et Yellow. Nous avons défini une interface ShapeColorFactory avec deux RedCircleFactory et YellowSquareFactory. Le code suivant pour expliquer ce concept:
interface ShapeColorFactory
{
public Shape getShape();
public Color getColor();
}
class RedCircleFactory implements ShapeColorFactory
{
@Override
public Shape getShape() {
return new Circle();
}
@Override
public Color getColor() {
return new Red();
}
}
class YellowSquareFactory implements ShapeColorFactory
{
@Override
public Shape getShape() {
return new Square();
}
@Override
public Color getColor() {
return new Yellow();
}
}
Ici la différence entre FactoryMethod et AbstractFactory. Factory Method comme simplement renvoyer une classe concrète d'une interface mais Abstract Factory renvoyer factory of factory. En d'autres termes, Abstract Factory renvoie différentes combinaisons d'une série d'interfaces.
J'espère que mon explication est utile.
Extension de John Feminella answer:
Apple, Banana, Cherry implémente FruitFactory et utilise une méthode appelée Create qui est seul responsable de la création de Apple ou de Banana ou Cerise. Vous avez terminé, avec votre méthode Factory.
Maintenant, vous voulez Create une salade spéciale de vos fruits et voici votre Abstract Factory. Abstract Factory sait comment créer votre salade spéciale à partir de pommes, bananes et cerises.
public class Apple implements Fruit, FruitFactory {
public Fruit Create() {
// Apple creation logic goes here
}
}
public class Banana implements Fruit, FruitFactory {
public Fruit Create() {
// Banana creation logic goes here
}
}
public class Cherry implements Fruit, FruitFactory {
public Fruit Create() {
// Cherry creation logic goes here
}
}
public class SpecialSalad implements Salad, SaladFactory {
public static Salad Create(FruitFactory[] fruits) {
// loop through the factory and create the fruits.
// then you're ready to cut and slice your fruits
// to create your special salad.
}
}
La principale différence dans ces usines réside dans le moment où vous voulez faire avec les usines et quand vous voulez l'utiliser.
Parfois, lorsque vous faites IOC (inversion du contrôle, par exemple injection de constructeur), vous savez que vous pouvez créer des objets solides. Comme mentionné dans l'exemple ci-dessus de fruits, si vous êtes prêt à créer des objets de fruits, vous pouvez utiliser le simple modèle d'usine.
Mais souvent, vous ne voulez pas créer d'objets solides, ils viendront plus tard dans le déroulement du programme. Mais la configuration vous indique le type d’usine que vous voulez utiliser au début, au lieu de créer des objets, vous pouvez transférer des fabriques dérivées d’une classe d’usine commune au constructeur dans IOC.
Donc, je pense que cela concerne également la durée de vie et la création de l'objet.
Factory Method et Abstract Factory maintiennent les clients découplés des types concrets. Les deux créent des objets, mais la méthode Factory utilise l'héritage, tandis que Abstract Factory utilise la composition.
Le Factory Method est hérité dans des sous-classes pour créer les objets concrets (produits), tandis que Abstract Factory fournit une interface pour la création de la famille de produits connexes. La sous-classe de ces interfaces définit comment créer des produits connexes.
Ensuite, ces sous-classes lorsqu’elles sont instanciées sont transmises aux classes de produits où elles sont utilisées en tant que type abstrait. Les produits associés dans un Abstract Factory sont souvent implémentés avec Factory Method.
Par définition, nous pouvons faire ressortir les différences de deux:
Factory: une interface est utilisée pour créer un objet, mais la sous-classe décide de la classe à instancier. La création d'objet est faite quand c'est nécessaire.
Abstract Factory: le motif Abstract Factory agit comme une super-usine qui crée d’autres usines. Dans le modèle Abstract Factory, une interface est chargée de créer un ensemble d'objets associés, ou d'objets dépendants, sans spécifier leurs classes concrètes.
Ainsi, dans les définitions ci-dessus, nous pouvons souligner une différence particulière. c'est-à-dire que le motif Factory est responsable de la création des objets et que Abstract Factory est responsable de la création d'un ensemble d'objets associés. évidemment à la fois via une interface.
Modèle d'usine:
public interface IFactory{
void VehicleType(string n);
}
public class Scooter : IFactory{
public void VehicleType(string n){
Console.WriteLine("Vehicle type: " + n);
}
}
public class Bike : IFactory{
public void VehicleType(string n) {
Console.WriteLine("Vehicle type: " + n);
}
}
public interface IVehicleFactory{
IFactory GetVehicleType(string Vehicle);
}
public class ConcreteVehicleFactory : IVehicleFactory{
public IFactory GetVehicleType(string Vehicle){
switch (Vehicle){
case "Scooter":
return new Scooter();
case "Bike":
return new Bike();
default:
return new Scooter();
}
}
class Program{
static void Main(string[] args){
IVehicleFactory factory = new ConcreteVehicleFactory();
IFactory scooter = factory.GetVehicleType("Scooter");
scooter.VehicleType("Scooter");
IFactory bike = factory.GetVehicleType("Bike");
bike.VehicleType("Bike");
Console.ReadKey();
}
}
Modèle d'usine abstrait:
interface IVehicleFactory{
IBike GetBike();
IScooter GetScooter();
}
class HondaFactory : IVehicleFactory{
public IBike GetBike(){
return new FZS();
}
public IScooter GetScooter(){
return new FZscooter();
}
}
class HeroFactory: IVehicleFactory{
public IBike GetBike(){
return new Pulsur();
}
public IScooter GetScooter(){
return new PulsurScooter();
}
}
interface IBike
{
string Name();
}
interface IScooter
{
string Name();
}
class FZS:IBike{
public string Name(){
return "FZS";
}
}
class Pulsur:IBike{
public string Name(){
return "Pulsur";
}
}
class FZscooter:IScooter {
public string Name(){
return "FZscooter";
}
}
class PulsurScooter:IScooter{
public string Name(){
return "PulsurScooter";
}
}
enum MANUFACTURERS
{
HONDA,
HERO
}
class VehicleTypeCheck{
IBike bike;
IScooter scooter;
IVehicleFactory factory;
MANUFACTURERS manu;
public VehicleTypeCheck(MANUFACTURERS m){
manu = m;
}
public void CheckProducts()
{
switch (manu){
case MANUFACTURERS.HONDA:
factory = new HondaFactory();
break;
case MANUFACTURERS.HERO:
factory = new HeroFactory();
break;
}
Console.WriteLine("Bike: " + factory.GetBike().Name() + "\nScooter: " + factory.GetScooter().Name());
}
}
class Program
{
static void Main(string[] args)
{
VehicleTypeCheck chk = new VehicleTypeCheck(MANUFACTURERS.HONDA);
chk.CheckProducts();
chk= new VehicleTypeCheck(MANUFACTURERS.HERO);
chk.CheckProducts();
Console.Read();
}
}
Abstract Factory est un modèle permettant de créer différents types d'interfaces. Supposons que votre projet nécessite d'analyser différents types de fichiers .csv contenant des informations spécifiques à la quantité, au prix et aux articles. Certains contiennent par exemple des données sur les fruits, puis sur les chocolats. une usine abstraite vous renvoie votre analyseur et votre modificateur, puis cette usine peut vous renvoyer un objet analyseur Chocolate, un objet analyseur de fruits, etc., et de même, Modificateur Factory peut renvoyer un objet modificateur Chocolate, un objet modificateur Fruit, etc.
Vérifiez ici: http://www.allapplabs.com/Java_design_patterns/abstract_factory_pattern.htm il semble que la méthode Factory utilise une classe particulière (non abstraite) comme classe de base, tandis que Abstract factory utilise une classe abstraite pour cette. De même, si vous utilisez une interface au lieu d'une classe abstraite, le résultat sera une implémentation différente du motif Abstract Factory.
:RÉ
Je pense que nous pouvons comprendre la différence entre ces deux en voyant un exemple de code Java8:
interface Something{}
interface OneWhoCanProvideSomething {
Something getSomething();
}
interface OneWhoCanProvideCreatorsOfSomething{
OneWhoCanProvideSomething getCreator();
}
public class AbstractFactoryExample {
public static void main(String[] args) {
//I need something
//Let's create one
Something something = new Something() {};
//Or ask someone (FACTORY pattern)
OneWhoCanProvideSomething oneWhoCanProvideSomethingOfTypeA = () -> null;
OneWhoCanProvideSomething oneWhoCanProvideSomethingOfTypeB = () -> null;
//Or ask someone who knows soemone who can create something (ABSTRACT FACTORY pattern)
OneWhoCanProvideCreatorsOfSomething oneWhoCanProvideCreatorsOfSomething = () -> null;
//Same thing, but you don't need to write you own interfaces
Supplier<Something> supplierOfSomething = () -> null;
Supplier<Supplier<Something>> supplierOfSupplier = () -> null;
}
}
Maintenant, la question est de savoir quel mode de création devez-vous utiliser et pourquoi: Le premier moyen (pas de modèle, mais simplement du constructeur): créer par vous-même n'est pas une bonne idée, vous devez faire tout le travail et votre code client est lié à la mise en œuvre particulière.
La deuxième manière (à l'aide du modèle Factory): vous offre l'avantage de pouvoir passer n'importe quel type d'implémentation, ce qui peut fournir un type différent de quelque chose en fonction d'une condition (peut-être un paramètre passé à la méthode creational).
La troisième façon (en utilisant le motif Abstract Factory): Cela vous donne plus de flexibilité. Vous pouvez trouver différents types de créateurs de quelque chose en fonction de certaines conditions (peut-être un paramètre passé).
Notez que vous pouvez toujours vous échapper avec le motif Factory en combinant deux conditions (ce qui augmente légèrement la complexité du code et le couplage). Je suppose que c'est pourquoi nous voyons rarement des cas d'utilisation réels du motif de la fabrique abstraite.