Quelle est la différence fondamentale entre les motifs d'usine et les motifs d'usine abstraits?

Avec le modèle Factory, vous produisez des instances de mise en oeuvre ( Apple, Banana, Cherry, etc.) d'une interface particulière - par exemple, IFruit.

Avec le modèle Abstract Factory, vous fournissez un moyen pour quiconque de fournir sa propre usine. Cela permet à votre entrepôt d'être un IFruitFactoryou un IJuiceFactory, sans que votre entrepôt ne sache quoi que ce soit sur les fruits ou les jus.

Source de cette information tirée de: http://java.dzone.com/news/intro-design-patterns-abstract

Usine abstraite vs méthode d'usine

Les méthodes d'une usine abstraite sont implémentées en tant que méthodes d'usine. Le modèle abstrait d'usine et le modèle de méthode d'usine dissocient le système client des classes d'implémentation réelles par le biais des types abstraits et des usines. La méthode Factory crée des objets par héritage, alors que la fabrique abstraite crée des objets par composition.

Le modèle d'usine abstraite se compose d'une usine abstraite, d'une usine concrète, d'un produit abstrait, d'un produit concret et d'un client.

Comment mettre en œuvre

Le modèle d'usine abstrait peut être implémenté à l'aide du modèle de méthode d'usine, du modèle de prototype ou du modèle 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 responsable de la création de produits appartenant à une même famille, tandis que le modèle Abstract Factory traite de plusieurs familles de produits.

Factory Method utilise des interfaces et des classes abstraites pour dissocier le client de la classe du générateur et des produits résultants. Abstract Factory possède un générateur qui est un conteneur pour plusieurs méthodes d'usine, ainsi que des interfaces découplant le client du générateur et des produits.

Quand utiliser le modèle de méthode d'usine

Utilisez le modèle Factory Method lorsqu'il est nécessaire de dissocier un client d'un produit particulier qu'il utilise. Utilisez la méthode Factory pour décharger un client de la responsabilité de la création et de la configuration des instances d'un produit.

Quand utiliser le modèle d'usine abstraite

Utilisez le modèle Abstract Factory lorsque les clients doivent être découplés des classes de produits. Particulièrement utile pour la configuration et la modification de programmes. Le modèle Abstract Factory peut également imposer des contraintes sur les classes à utiliser avec les autres. La fabrication de nouvelles usines de béton peut demander beaucoup de travail.

Exemples:

Exemple d'usine abstraite 1

Cette spécification pour les disques pour préparer différents types de pâtes dans un fabricant de pâtes est la fabrique abstraite, et chaque disque spécifique est une fabrique. toutes les usines (disques de pâtes) héritent de leurs propriétés de l'usine abstraite. Chaque disque individuel contient des informations sur la façon de créer les pâtes, et pas le fabricant de pâtes.

Exemple d'usine abstraite 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 de produits abstraits. Les matrices correspondent à la Concrete Factory, car elles créent un produit en béton. Chaque catégorie de pièce (hotte, porte, etc.) correspond au produit abstrait. Les pièces spécifiques (c.-à-d. 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 produits. La division de la société de jouets qui fabrique un type spécifique de jouet (cheval ou voiture) correspond à 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 IProduits :)

[Mise à jour selon les commentaires]
Ce que j'ai écrit plus tôt n'est pas correct du moins selon Wikipédia . Une usine abstraite est simplement une interface d'usine. Avec lui, vous pouvez changer vos usines au moment de l'exécution, pour autoriser différentes usines dans différents contextes. Les exemples pourraient être différentes usines pour différents OS, fournisseurs SQL, middleware-pilotes, etc.

Le motif de l'usine abstraite

• Fournir 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 est qu'avec le modèle Abstract Factory, une classe délègue la responsabilité de l'instanciation d'objet à un autre objet via la composition tandis que le modèle Factory Method utilise l'héritage et s'appuie sur une sous-classe pour gérer l'instanciation d'objet souhaitée.

• En fait, l'objet délégué utilise fréquemment des méthodes d'usine 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 résument le processus d'instanciation d'objet. Ils masquent la façon dont les objets sont créés et contribuent à rendre le système global indépendant de la façon 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'objets se concentrent sur la délégation de l'instanciation à un autre objet Abstract Factory

Référence: Factory vs Abstract Factory

Méthode de fabrique: vous disposez d'une fabrique qui crée des objets qui dérivent d'une classe de base particulière

Usine abstraite: vous avez une usine qui crée d' autres usines , et ces usines 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 associés.

L'usine abstraite est une interface pour créer des objets associés, mais la méthode d'usine est une méthode. L'usine abstraite est implémentée par la méthode d'usine.

Différence de base:

Factory: crée des objets sans exposer la logique d'instanciation au client.

Méthode d'usine : définissez une interface pour créer un objet, mais laissez les sous-classes décider de la classe à instancier. La méthode Factory permet à une classe de reporter l'instanciation aux sous-classes

Abstract Factory : fournit une interface pour créer des familles d'objets liés ou dépendants sans spécifier leurs classes concrètes.

Le modèle AbstractFactory utilise la composition pour déléguer la responsabilité de créer un objet à une autre classe tandis que le modèle de méthode Factory utilise l'héritage et s'appuie sur une classe ou une sous-classe dérivée pour créer l'objet

Des articles oodesign :

Diagramme de classe d' usine :

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;
   }
}

Un exemple d'usine non statique implémentant FactoryMethod est disponible dans cet article:

Modèles de conception: méthode Factory vs Factory vs Abstract Factory

Quand l'utiliser: le client a juste besoin d'une classe et ne se soucie pas de l'implémentation concrète qu'il reçoit.

Classe de méthode d'usine digaram:

Quand l'utiliser: Le client ne sait pas quelles classes concrètes il devra créer au moment de l'exécution, mais veut juste obtenir une classe qui fera le travail.

Diagramme de classe abstraite d'usine de dzone

Quand l'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 l'implémentation.

Les exemples de code source dans les articles ci-dessus sont très bons pour comprendre clairement les concepts.

Question SE associée avec un exemple de code:

Modèle d'usine. Quand utiliser les méthodes d'usine?

Différences:

1. Les classes Factory abstraites sont souvent implémentées avec les méthodes Factory, mais elles peuvent également être implémentées à l'aide de Prototype
2. Les conceptions commencent par utiliser la méthode d'usine (moins compliquée, plus personnalisable, les sous-classes prolifèrent) et évoluent vers d'autres modèles de création (plus flexibles, plus complexes) où plus de flexibilité est nécessaire.
3. Les méthodes d'usine sont généralement appelées dans les méthodes de modèle.

Autres articles utiles:

méthode_usine de fabrication de source

abstract_factory de sourcemaking

modèle de conception abstraite d'usine de journaldev

Exemple / scénario pour Abstract Factory

Je vis dans un endroit où il pleut pendant la saison des pluies, la neige en hiver et chaude et ensoleillée 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 je demande des vêtements / articles pour me protéger. Le magasinier me donne l'article approprié selon l'environnement et la profondeur de ma poche. Les articles qu'il me donne sont de même niveau de qualité et de prix. Puisqu'il est au courant de mes normes, il lui est facile de le faire. Mais quand un homme riche de l'autre côté de la rue arrive avec les mêmes exigences, il obtient un article de marque cher. Une chose notable est que tous les articles qu'il me donne se complètent en termes de qualité, de standard et de coût. On peut dire qu'ils vont ensemble. C'est la même chose avec les objets que ce gars riche obtient.

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 abstrait. Les éléments que nous obtenons avec des éléments abstraits et moi et les riches en tant que clients en perspective. Nous n'avons besoin que du produit / article qui correspond à nos besoins.

Maintenant, je me vois facilement envisager une boutique en ligne qui fournit un ensemble de services à ses nombreux clients. Chaque client appartient à l'un des trois groupes. Lorsqu'un utilisateur d'un groupe premium ouvre le site, il obtient une excellente interface utilisateur, un volet de publicité hautement personnalisé, plus d'options dans les menus, etc. et une interface légèrement moins ergonomique. Le dernier est mon type d'utilisateur, un utilisateur de «groupe libre». Je suis juste assez servi pour ne pas être offensé. L'interface utilisateur est un strict minimum, les publicités sont tellement éloignées que je ne sais pas ce qui s'y trouve, enfin le menu ne fait que se déconnecter.

Si j'ai la chance de construire quelque chose comme ce site, je considérerais certainement Abstract Factory Pattern.

Produits abstraits: volet publicitaire, menu, peintre d'interface utilisateur.
Abstract Factory: Expérience utilisateur de la boutique en ligne
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'un entretien, vous devez aider l'enquêteur à comprendre où se situe la confusion.

Commençons par le fait qu'il n'y a pas de motif concret qui s'appelle juste "Factory". Il existe un modèle appelé "Abstract Factory" et un modèle appelé "Factory Method".

Alors, qu'est-ce que "Factory" signifie alors? l'un des éléments suivants (tout peut être considéré comme correct, selon 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 " Factory Method ".
• Certaines personnes l'utilisent comme un nom plus général pour tous les modèles d'usine / création. Par exemple, "Abstract Factory" et "Factory Method" sont des usines.

Et, malheureusement , beaucoup de gens utilisent "Factory" pour désigner un autre type d'usine, qui crée une ou plusieurs usines (ou leurs interfaces). Sur la base de leur théorie:

Le produit implémente IProduct, qui est créé par Factory, qui implémente IFactory, qui est créé par AbstractFactory.

Pour comprendre à quel point c'est idiot, continuons notre équation:

AbstractFactory implémente IAbstractFactory, qui est créé par ... AbstractAbstractFactory ???

J'espère que vous voyez le point. Ne vous trompez pas, et s'il vous plaît, n'inventez pas des choses qui n'existent pas pour une raison.

-

PS : Factory for Products est AbstractFactory, et Factory for Abstract Factories serait également 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 des manuels sont déjà fournies par d'autres réponses. J'ai pensé que j'en fournirais également un exemple.

Voici donc PizzaIngredientsFactoryune usine 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 de fabrique en soi. Like createDough()est en soi une méthode d'usine dont les implémentations concrètes seront fournies par des sous-classes comme NYPizzaIngredientsFactory. Ainsi, l'utilisation de chaque emplacement différent peut créer des instances d'ingrédients concrets qui appartiennent à leur emplacement.

Méthode d'usine

Fournit une instance de mise en œuvre concrète

Dans l'exemple:
- createDough()- fournit une mise en œuvre 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 associés

Dans l'exemple:
- PizzaIngredientsFactoryest une usine abstraite car elle permet de créer un ensemble d'objets associés comme 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 à apporter à la réponse de John comme suit:

L'usine abstraite est une usine d'usines!

Avec la « méthode usine » (parce que « Factory » est ambigu), vous produisez des implémentations ( Lemon, Orange, etc.) d'une interface particulière - par exemple, IFruit. Cette usine pourrait être appelée CitricFruitFactory.

Mais maintenant, vous voulez créer un autre type de fruit que CitricFruitFactory n'est pas en mesure de créer. Peut-être que le code de CitricFruitFactoryn'aurait pas de sens si vous en créez un Strawberry(la fraise n'est pas un fruit citrique!).

Ainsi , vous pouvez créer une nouvelle usine appelée RedFruitFactoryqui produit Strawberry, Raspberryetc.

Comme l'a dit John Feminella: "Avec le modèle Abstract Factory, vous produisez des implémentations d'une interface Factory particulière - par exemple IFruitFactory. Chacun sait comment créer différents types de fruits."

Ces implémentations de IFruitFactorysont CitricFruitFactoryet RedFruitFactory!

Mes sources sont: StackOverflow, tutorialspoint.com, programmers.stackexchange.comet CodeProject.com.

Factory Method(également appelé Factory) est destiné au client de découplage d'une Interfaceimplémentation. Par exemple, nous avons une Shapeinterface avec deux Circleet Squareimplémentations. Nous avons défini une classe d'usine avec une méthode d'usine avec un paramètre déterminant tel qu'une Typenouvelle implémentation d' Shapeinterface associée .

Abstract Factorycontient plusieurs méthodes d'usine ou une interface d'usine par plusieurs implémentations d'usine. Pour l' échantillon suivant ci - dessus , nous avons une Colorinterface avec deux Redet Yellowmises en œuvre. Nous avons défini une ShapeColorFactoryinterface avec deux RedCircleFactoryet YellowSquareFactory. 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();
    }
} 

Voici la différence entre FactoryMethodet AbstractFactory. Factory Methodcomme simplement retourner une classe concrète d'une interface mais Abstract Factoryretourner factory of factory. En d'autres termes, Abstract Factoryretournez une combinaison différente d'une série d'interfaces.

J'espère que mon explication sera utile.

La différence majeure dans ces usines est quand ce que vous voulez faire avec les usines et quand vous voulez l'utiliser.

Parfois, lorsque vous faites de l'IOC (inversion de contrôle, par exemple injection de constructeur), vous savez que vous pouvez créer des objets solides. Comme mentionné dans l'exemple ci-dessus des fruits, si vous êtes prêt à créer des objets de fruits, vous pouvez utiliser un modèle d'usine simple .

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 souhaitez utiliser au démarrage, au lieu de créer des objets, vous pouvez transmettre les usines dérivées d'une classe d'usine commune au constructeur dans IOC.

Donc, je pense que c'est aussi sur la durée de vie et la création de l'objet.

Les deux Factory Methodet Abstract Factorygarder les clients découplés des types de béton. Les deux créent des objets, mais la Factoryméthode utilise l'héritage tandis que la Abstract Factorycomposition.

Le Factory Methodest hérité des sous-classes pour créer les objets concrets (produits) tandis que Abstract Factoryfournir une interface pour créer la famille de produits liés et la sous-classe de ces interfaces définit comment créer des produits liés.

Ensuite, ces sous-classes une fois instanciées sont passées dans des classes de produits où elles sont utilisées comme type abstrait. Les produits associés dans un Abstract Factorysont souvent implémentés à l'aide de Factory Method.

Extension de la réponse de John Feminella:

Apple, Banana, CherryMet en œuvre FruitFactoryet qui a une méthode appelée Createqui est seul responsable de la création d' Apple ou de banane ou de cerise. Vous avez terminé, avec votre Factoryméthode.

Maintenant, vous voulez Createune salade spéciale de vos fruits et voici votre usine abstraite . Abstract Factory sait comment créer votre salade spéciale à partir de pomme, de banane et de cerise.

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

Par définition, nous pouvons faire glisser 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 se fait lorsqu'elle est requise.

Abstract Factory: le modèle Abstract Factory agit comme une super-usine qui crée d'autres usines. Dans le modèle Abstract Factory, une interface est responsable de la création d'un ensemble d'objets lié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 Factory pattern est responsable de la création d'objets et 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();
 }
}

Motif abstrait d'usine:

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();
        }
    }

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 (pas abstraite) comme classe de base tandis que la fabrique Abstract utilise une classe abstraite pour cela. De plus, si vous utilisez une interface au lieu d'une classe abstraite, le résultat sera une implémentation différente du modèle Abstract Factory.

:RÉ

Abstract Factory est un modèle pour créer différents types d'interfaces. Supposons que vous ayez un projet qui vous oblige à analyser différents types de fichiers csv contenant des informations spécifiques sur la quantité, le prix et l'article, comme certains contiennent des données sur les fruits, d'autres sur les chocolats, puis après l'analyse, vous devez mettre à jour ces informations dans leur base de données correspondante, maintenant vous pouvez avoir une fabrique abstraite vous renvoyant une fabrique d'analyseurs et de modificateurs, puis cette fabrique d'analyseurs peut vous renvoyer un objet analyseur de chocolat, un objet analyseur de fruits, etc. et de la même manière, la fabrique de modificateurs peut renvoyer un objet modificateur de chocolat, un objet modificateur de fruits, etc.

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: La première façon (pas de modèle, juste un constructeur simple): 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 façon (en utilisant le modèle Factory): vous offre l'avantage que vous pouvez passer n'importe quel type d'implémentation, qui peut fournir un type différent de quelque chose en fonction d'une condition (peut-être un paramètre passé à la méthode de création).

La troisième façon (en utilisant le modèle Abstract Factory): Cela vous donne plus de flexibilité. Vous pouvez trouver différents types de créateurs de quelque chose en fonction d'une condition (peut-être un paramètre passé).

Notez que vous pouvez toujours vous éloigner du modèle Factory en combinant deux conditions ensemble (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 modèle Abstract Factory.