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

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

    Avec le motif 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 fournissez à quiconque le moyen de fournir sa propre usine. Cela permet à votre entrepôt d’être soit une IFruitFactory soit une IJuiceFactory , sans que votre entrepôt ne connaisse les fruits ou les jus.

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

    Méthode abstraite contre 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 de fabrique découplent le système client des classes d’implémentation actuelles en passant par les types abstraits et les fabriques. La méthode d’usine crée des objects par inheritance, où la fabrique abstraite crée des objects à travers la composition.

    Le modèle de fabrique abstraite se compose d’une AbstractFactory, de ConcreteFactory, de AbstractProduct, de ConcreteProduct et d’un client.

    Comment mettre en œuvre

    Le motif d’usine abstrait peut être implémenté en utilisant le modèle de méthode d’usine, le modèle de prototype ou le motif singleton. L’object ConcreteFactory peut être implémenté en tant que Singleton car une seule instance de l’object ConcreteFactory est requirejse.

    Le modèle Factory Method est une version simplifiée du motif Abstract Factory. Le modèle Factory Method est responsable de la création de produits appartenant à une famille, tandis que le modèle Abstract Factory traite de plusieurs familles de produits.

    Factory Method 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 a un générateur qui est un conteneur pour plusieurs méthodes d’usine, ainsi que des interfaces qui découplent 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 qu’il utilise. Utilisez la méthode d’usine pour décharger un client de la responsabilité de créer et de configurer des instances d’un produit.

    Quand utiliser le motif d’usine abstrait

    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 de fabrique abstraite peut également imposer des contraintes sur les classes à utiliser avec les autres. Faire de nouvelles usines de béton peut représenter 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 Abstract Factory, et chaque disque spécifique est une Factory. toutes les usines (disques de fabricant de pâtes) héritent de leurs propriétés de la fabrique abstraite. Chaque disque individuel contient des informations sur la manière de créer les pâtes, contrairement au fabricant de pâtes.

    Exemple d’usine abstraite 2:

    L’équipement de masortingçage correspond à la fabrique abstraite, car il s’agit d’une interface pour les opérations qui créent des objects de produit abstraits. Les masortingces correspondent à l’usine de béton, car elles créent un produit concret. Chaque catégorie de pièce (capot, 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 objects de produits. La division du fabricant de jouets qui fabrique un type de jouet spécifique (cheval ou voiture) correspond au ConcreteCreator.

    Modèle d’usine: L’usine produit des implémentations IProduct

    Abstract Factory Pattern: Une usine fabrique des IFactories, qui à leur tour produisent des IProduct 🙂

    [Mise à jour selon les commentaires]
    Ce que j’ai écrit plus tôt n’est pas correct au moins selon Wikipedia . Une usine abstraite est simplement une interface d’usine. Avec elle, vous pouvez basculer vos usines à 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, pilotes de middleware, etc.

    Le modèle d’usine abstraite

    • Fournir une interface pour créer des familles d’objects associés ou dépendants sans spécifier leurs classes concrètes.

    • Le motif de la fabrique abstraite est très similaire au motif de la méthode d’usine. Une différence entre les deux est que, avec le modèle Abstract Factory, une classe délègue la responsabilité de l’instanciation d’object à un autre object via la composition, tandis que le modèle Factory Method utilise l’inheritance et s’appuie sur une sous-classe pour gérer l’instanciation d’object souhaitée.

    • En réalité, l’object délégué utilise fréquemment des méthodes d’usine pour effectuer l’instanciation!

    Motif d’usine

    • Les motifs d’usine sont des exemples de motifs créatifs

    • Les patterns de création abstraite le processus d’instanciation d’object. Ils cachent comment les objects sont créés et aident à rendre le système global indépendant de la façon dont ses objects sont créés et composés.

    • Les modèles de création de classe se concentrent sur l’utilisation de l’inheritance pour décider de l’object à instancier

    • Les motifs de création d’objects se concentrent sur la délégation de l’instanciation à un autre object

    Référence: Usine vs usine abstraite

    Méthode d’usine: Vous avez une fabrique qui crée des objects 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 objects dérivés de classes de base. Vous faites cela parce que vous ne voulez souvent pas créer un seul object (comme avec la méthode Factory) – vous voulez plutôt créer une collection d’objects associés.

    La fabrique abstraite est une interface permettant de créer des objects 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.

    entrer la description de l'image ici

    Différence de base:

    Factory: crée des objects sans exposer la logique d’instanciation au client.

    Méthode d’usine : Définissez une interface pour créer un object, mais laissez les sous-classes décider quelle classe instancier. La méthode Factory permet à une classe de différer l’instanciation aux sous-classes

    Fabrique abstraite : fournit une interface pour créer des familles d’objects 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 object à une autre classe, tandis que le modèle de méthode Factory utilise l’inheritance et s’appuie sur une classe ou une sous-classe dérivée pour créer un object.

    Des articles oodesign :

    Diagramme de classe d’ usine :

    entrer la description de l'image ici

    Exemple: StaticFactory

      public class ShapeFactory { //use getShape method to get object of type shape public static Shape getShape(Ssortingng 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 d’implémentation FactoryMethod de Factory non statique est disponible dans cet article:

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

    Quand utiliser: Le client a juste besoin d’une classe et peu importe l’implémentation concrète qu’il obtient.

    Classe de méthode d’usine digaram:

    entrer la description de l'image ici

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

    Diagramme de classe Factory abstraite de dzone

    entrer la description de l'image ici

    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 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 exemple de code:

    Motif 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 aussi être implémentées avec Prototype
    2. Les conceptions commencent par utiliser la méthode de fabrication (moins compliquée, plus personnalisable, les sous-classes prolifèrent) et évoluent vers d’autres modèles de création (plus flexibles, plus complexes) nécessitant davantage de flexibilité.
    3. 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 fabrication

    abstract_factory de sourcemaking

    Modèle de conception d’usine abstraite de journaldev

    Exemple / scénario pour la fabrique abstraite

    Je vis dans un endroit où il pleut pendant la saison des pluies, il neige en hiver et 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 / 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 du même niveau de qualité et de prix. Comme il est au courant de mes normes, il lui est facile 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 notable est que tous les éléments qu’il me donne se complètent en termes de qualité, de standard et de coût. On peut dire qu’ils vont ensemble. Le même est le cas avec les articles 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 une boutique abstraite. Les objects que nous recevons avec des objects abstraits et moi et les riches comme clients potentiels. Tout ce dont nous avons besoin est le produit / article qui convient à nos besoins.

    Maintenant, je peux facilement voir un magasin en ligne qui fournit un ensemble de services à ses nombreux clients. Chaque client appartient à l’un des trois groupes. Quand un utilisateur du groupe premium ouvre le site, il obtient une excellente interface utilisateur, un volet de publicité hautement personnalisé, plus d’options dans les menus, etc. Ces mêmes fonctionnalités sont présentées à l’utilisateur Gold, mais les fonctionnalités du menu sont moins nombreuses, et l’interface utilisateur légèrement moins ergonomique. Last est mon genre d’utilisateur, un utilisateur «groupe libre». Je suis juste assez servi pour que je ne sois pas offensé. L’interface utilisateur est un ssortingct minimum, les publicités sont tellement hors de propos que je ne sais pas ce qu’il y a dedans, enfin le menu ne se déconnecte que.

    Si j’ai une chance de construire quelque chose comme ce site, je considérerais certainement le modèle d’usine abstraite.

    Produits abstraits: volet de publicité, menu, peintre d’interface utilisateur.
    Fabrique abstraite: expérience utilisateur Web Store
    Concreate Factory: Expérience utilisateur Premium, Expérience utilisateur Gold, Expérience utilisateur générale.

     //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 aussi.

    Ainsi, la PizzaIngredientsFactory est une usine abstraite car elle fournit des méthodes pour créer une famille de produits connexes.

    Notez que chaque méthode de la fabrique Abstract est une méthode Factory en soi. Like createDough() est en soi une méthode de fabrique dont les implémentations concrètes seront fournies par des sous-classes telles que NYPizzaIngredientsFactory . Ainsi, l’utilisation de chaque emplacement différent peut créer des instances d’ingrédients concrets appartenant à leur emplacement.

    Méthode d’usine

    Fournit une instance d’implémentation concrète

    Dans l’exemple:
    createDough() – fournit une implémentation concrète pour la pâte. Donc, c’est une méthode d’usine

    Usine abstraite

    Fournit une interface pour créer une famille d’objects associés

    Dans l’exemple:
    PizzaIngredientsFactory est une usine abstraite car elle permet de créer un ensemble d’objects apparentés tels que la Dough , les Clams , la Sauce . Pour créer chaque famille d’objects, il fournit une méthode d’usine.

    Exemple de motifs de conception Head First

    Beaucoup de gens se sentiront peut-être surpris, mais cette question est incorrecte . Si vous entendez cette question lors d’une entrevue, vous devez aider l’intervieweur à comprendre où se trouve la confusion.

    Commençons par le fait qu’il n’y a pas de modèle concret appelé simplement “Factory”. Il existe un motif appelé “Abstract Factory”, et il existe un motif appelé “Factory Method”.

    Alors, que signifie “Factory” alors? l’un des suivants (tout peut être considéré comme correct, selon l’étendue de la référence):

    • Certaines personnes l’utilisent comme un alias (raccourci) pour ” Abstract Factory “.
    • Certaines personnes l’utilisent comme un alias (raccourci) pour ” Factory Method “.
    • Certaines personnes l’utilisent comme nom plus général pour tous les motifs 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 des usines ou des usines (ou leurs interfaces). Basé sur leur théorie:

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

    Pour comprendre à quel point c’est stupide, continuons notre équation:

    AbstractFactory implémente IAbstractFactory, 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.

    PS : Factory for Products est AbstractFactory et Factory for Abstract Factories ne serait qu’un autre exemple de AbstractFactory.

    Une méthode d’usine est une méthode non statique qui renvoie une classe de base ou un type d’interface et qui est implémentée dans une hiérarchie pour permettre la création polymorphe. Une méthode d’usine doit être définie / implémentée par une classe et une ou plusieurs sous-classes de la classe. La classe et les sous-classes agissent chacune comme des usines. Cependant, nous ne disons pas qu’une méthode d’usine est une usine. Une Abstract Factory est une interface permettant de créer des familles d’objects associés ou dépendants sans spécifier leurs classes concrètes.

    Les usines abstraites sont conçues pour être substituables à l’exécution, de sorte qu’un système peut être configuré pour utiliser un implémenteur spécifique et concret d’une fabrique abstraite. Chaque usine abstraite est une usine, bien que chaque usine ne soit pas une usine abstraite. Les classes qui sont des usines, et non des usines abstraites, évoluent parfois vers des usines abstraites lorsqu’il est nécessaire de créer plusieurs familles d’objects associés ou dépendants.

    J’ai quelques points à apporter avec la réponse de John comme suit:

    L’usine abstraite est une usine d’usines!

    Avec la “Méthode d’usine” (parce que seule “Factory” est ambiguë), vous produisez des implémentations ( Lemon , Orange , etc.) d’une interface particulière, par exemple IFruit . Cette fabrique pourrait s’appeler CisortingcFruitFactory .

    Mais maintenant, vous voulez créer un autre type de fruit que CisortingcFruitFactory ne peut pas créer. Peut-être que le code de CisortingcFruitFactory n’aurait pas de sens si vous y créez une Strawberry (la fraise n’est pas un fruit cisortingque!).

    Vous pouvez donc créer une nouvelle usine appelée RedFruitFactory qui produit des Strawberry , des 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 sait comment créer différents types de fruits.”

    Les implémentations de IFruitFactory sont CisortingcFruitFactory et RedFruitFactory !

    Extension de John Feminella répondre:

    Apple , Banana , Cherry implémente FruitFactory et possède une méthode appelée Create qui est uniquement responsable de la création de Apple, Banana ou Cherry. Vous avez terminé, avec votre méthode Factory .

    Maintenant, vous voulez Create une salade spéciale à partir de vos fruits et votre Abstract Factory . Abstract Factory sait comment créer votre salade spéciale à partir de la pomme, de la banane et de la 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. } } 

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


    Factory Method (également appelée Factory ) est destinée au client de découplage d’une implémentation d’ Interface . Pour 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 déterminant 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 . 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 différence entre FactoryMethod et AbstractFactory . Factory Method comme retourne simplement une classe concrète d’une interface, mais retourne l’ factory of factory retour factory of factory . En d’autres termes, Abstract Factory renvoie une combinaison différente d’une série d’interfaces.


    J’espère que mon explication est utile.

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

    Parfois, lorsque vous effectuez une opération IOC (inversion du contrôle, par exemple, injection de constructeur), vous savez que vous pouvez créer des objects solides. Comme mentionné dans l’exemple ci-dessus des fruits, si vous êtes prêt à créer des objects de fruits, vous pouvez utiliser des motifs d’usine simples.

    Mais plusieurs fois, vous ne voulez pas créer d’objects solides, ils viendront plus tard dans le stream de programme. Mais la configuration vous indique le type de fabrique que vous souhaitez utiliser au démarrage, au lieu de créer des objects, vous pouvez transmettre des constructeurs dérivés d’une classe de fabrique commune au constructeur d’IOC.

    Donc, je pense aussi à la durée de vie et à la création de l’object.

    Par définition, nous pouvons faire ressortir les différences de deux:

    Factory: une interface est utilisée pour créer un object, mais la sous-classe décide de la classe à instancier. La création d’object est faite quand il est requirejs.

    Fabrique abstraite: le motif de l’usine abstraite agit comme une super-usine qui crée d’autres usines. Dans Abstract Pattern, une interface est responsable de la création d’un ensemble d’objects associés ou d’objects 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 de fabrique est responsable de la création d’objects et que Abstract Factory est responsable de la création d’un ensemble d’objects associés; évidemment à la fois via une interface.

    Motif d’usine:

     public interface IFactory{ void VehicleType(ssortingng n); } public class Scooter : IFactory{ public void VehicleType(ssortingng n){ Console.WriteLine("Vehicle type: " + n); } } public class Bike : IFactory{ public void VehicleType(ssortingng n) { Console.WriteLine("Vehicle type: " + n); } } public interface IVehicleFactory{ IFactory GetVehicleType(ssortingng Vehicle); } public class ConcreteVehicleFactory : IVehicleFactory{ public IFactory GetVehicleType(ssortingng Vehicle){ switch (Vehicle){ case "Scooter": return new Scooter(); case "Bike": return new Bike(); default: return new Scooter(); } } class Program{ static void Main(ssortingng[] args){ IVehicleFactory factory = new ConcreteVehicleFactory(); IFactory scooter = factory.GetVehicleType("Scooter"); scooter.VehicleType("Scooter"); IFactory bike = factory.GetVehicleType("Bike"); bike.VehicleType("Bike"); Console.ReadKey(); } } 

    Motif d’usine abstraite:

     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 { ssortingng Name(); } interface IScooter { ssortingng Name(); } class FZS:IBike{ public ssortingng Name(){ return "FZS"; } } class Pulsur:IBike{ public ssortingng Name(){ return "Pulsur"; } } class FZscooter:IScooter { public ssortingng Name(){ return "FZscooter"; } } class PulsurScooter:IScooter{ public ssortingng 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(ssortingng[] 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 (non abstraite) en tant que classe de base alors que la fabrique abstraite utilise une classe abstraite pour cela. De même, si vous utilisez une interface au lieu d’une classe abstraite, le résultat sera une implémentation différente du modèle de fabrique abstraite.

    :RÉ

    Factory Method et Abstract Factory permettent de Abstract Factory les clients des types concrets. Les deux créent des objects, mais la méthode Factory utilise l’inheritance alors que Abstract Factory utilise la composition.

    La Factory Method est héritée dans les sous-classes pour créer les objects concrets (produits) alors que Abstract Factory fournit une interface pour créer la famille de produits associés et la sous-classe de ces interfaces définit comment créer des produits connexes.

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

    Abstract Factory est un modèle pour créer différents types d’interfaces. Supposons que vous ayez un projet qui vous oblige à parsingr différents types de fichiers csv contenant des informations spécifiques sur la quantité, le prix et les articles, comme certaines contiennent des données sur les fruits et sur les chocolats, puis vous devez mettre à jour ces informations dans la firebase database correspondante. one abstract factory returning you parser and modifier factory and then this parser factory can return you Chocolate parser object,Fruit Parser Object etc. and similarly Modifier Factory can return Chocolate modifier object , Fruit Modifier object etc.

    I think we can understand the difference between these two by seeing a Java8 example code:

      interface Something{} interface OneWhoCanProvideSomething { Something getSomething(); } interface OneWhoCanProvideCreatorsOfSomething{ OneWhoCanProvideSomething getCreator(); } public class AbstractFactoryExample { public static void main(Ssortingng[] 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 supplierOfSomething = () -> null; Supplier> supplierOfSupplier = () -> null; } } 

    Now the question is which way of creation should you use and why: The first way (no pattern, just plain constructor): creating by yourself is not a good idea, you have to do all the work, and your client code is tied to the particular implementation.

    The second way (using Factory pattern): provides you the benefit that you can pass any type of implementation, which can provide different type of something based on some condition (maybe a parameter passed to creational method).

    The third way (using Abstract Factory pattern): This gives you more flexibility. You can find different types of creators of something based on some condition (maybe a parameter passed).

    Note that you can always get away with Factory pattern by combining two conditions together (which slightly increases code complexity, and coupling), I guess that’s why we rarely see real life use cases of Abstract Factory pattern.