Wat zijn de verschillen tussen ontwerppatronen voor abstracte fabrieken en fabrieken?

Ik weet dat er veel berichten zijn over de verschillen tussen deze twee patronen, maar er zijn een paar dingen die ik niet kan vinden.

Van wat ik heb gelezen, zie ik dat je met het patroon van de fabrieksmethode kunt definiëren hoe je een enkel concreet product maakt, maar de implementatie voor de klant verbergt omdat ze een generiek product zullen zien. Mijn eerste vraag gaat over de abstracte fabriek. Is het zijn rol om u in staat te stellen families van concrete objecten te maken (dat kan afhangen van de specifieke fabriek die u gebruikt) in plaats van slechts een enkel concreet object? Retourneert de abstracte fabriek slechts één heel groot object of veel objecten, afhankelijk van welke methoden je aanroept?

Mijn laatste twee vragen gaan over een enkel citaat dat ik niet volledig kan begrijpen en dat ik op verschillende plaatsen heb gezien:

Een verschil tussen de twee is dat
met het patroon van de abstracte fabriek, a
klasse delegeert de verantwoordelijkheid van
object instantiatie naar een ander object
via compositie terwijl de Factory
Methodepatroon gebruikt overerving en
vertrouwt op een subklasse om de af te handelen
gewenste objectinstantiatie.

Ik heb begrepen dat het patroon van de fabrieksmethode een Creator-interface heeft waardoor de ConcreteCreator de leiding heeft om te weten welk ConcreteProduct moet worden geïnstantieerd. Is dit wat het betekent door overerving te gebruiken om objectinstantiatie af te handelen?

Wat betreft dat citaat, hoe delegeert het patroon van de abstracte fabriek precies de verantwoordelijkheid van het maken van objecten aan een ander object via compositie? Wat betekent dit? Het lijkt erop dat het patroon van de abstracte fabriek in mijn ogen ook overerving gebruikt om het constructieproces uit te voeren, maar aan de andere kant leer ik nog steeds over deze patronen.

Alle hulp, vooral bij de laatste vraag, wordt zeer op prijs gesteld.

Antwoord 1, autoriteit 100%

Het verschil tussen de twee

Het belangrijkste verschil tussen een ‘fabrieksmethode’ en een ‘abstracte fabriek’ is dat de fabrieksmethode een methode is en een abstracte fabriek een object. Ik denk dat veel mensen deze twee termen door elkaar halen en ze door elkaar gaan gebruiken. Ik herinner me dat ik het moeilijk vond om precies het verschil te vinden toen ik ze leerde.

Omdat de fabrieksmethode slechts een methode is, kan deze worden overschreven in een subklasse, vandaar de tweede helft van uw citaat:

… het patroon van de fabrieksmethode gebruikt
overerving en vertrouwt op een subklasse
om het gewenste object te behandelen
instantiatie.

Het citaat gaat ervan uit dat een object hier zijn eigenfabrieksmethode aanroept. Daarom zou het enige dat de retourwaarde zou kunnen veranderen een subklasse zijn.

De abstracte fabriek is een object met meerdere fabrieksmethoden. Kijkend naar de eerste helft van je offerte:

… met het patroon Abstract Factory, een klasse
delegeert de verantwoordelijkheid van object
instantiatie naar een ander object via
compositie …

Wat ze zeggen is dat er een object A is, dat een Foo-object wil maken. In plaats van het Foo-object zelf te maken (bijvoorbeeld met een fabrieksmethode), krijgt het een anderobject (de abstracte fabriek) om het Foo-object te maken.

Codevoorbeelden

Om u het verschil te laten zien, is hier een fabrieksmethode die wordt gebruikt:

class A {
    public void doSomething() {
        Foo f = makeFoo();
        f.whatever();   
    }
    protected Foo makeFoo() {
        return new RegularFoo();
    }
}
class B extends A {
    protected Foo makeFoo() {
        //subclass is overriding the factory method 
        //to return something different
        return new SpecialFoo();
    }
}

En hier is een abstracte fabriek in gebruik:

class A {
    private Factory factory;
    public A(Factory factory) {
        this.factory = factory;
    }
    public void doSomething() {
        //The concrete class of "f" depends on the concrete class
        //of the factory passed into the constructor. If you provide a
        //different factory, you get a different Foo object.
        Foo f = factory.makeFoo();
        f.whatever();
    }
}
interface Factory {
    Foo makeFoo();
    Bar makeBar();
    Aycufcn makeAmbiguousYetCommonlyUsedFakeClassName();
}
//need to make concrete factories that implement the "Factory" interface here

Antwoord 2, autoriteit 24%

Abstract factorymaakt een basisklasse met abstracte methoden die methoden definiëren voor de objecten die moeten worden gemaakt. Elke fabrieksklasse die de basisklasse afleidt, kan zijn eigen implementatie van elk objecttype maken.

Fabrieksmethodeis slechts een eenvoudige methode die wordt gebruikt om objecten in een klasse te maken. Het wordt meestal toegevoegd in de geaggregeerde root (de klasse Orderheeft een methode met de naam CreateOrderLine)

Abstracte fabriek

In het onderstaande voorbeeld ontwerpen we een interface zodat we het aanmaken van wachtrijen kunnen loskoppelen van een berichtensysteem en daarom implementaties kunnen maken voor verschillende wachtrijsystemen zonder de codebasis te hoeven veranderen.

interface IMessageQueueFactory
{
  IMessageQueue CreateOutboundQueue(string name);
  IMessageQueue CreateReplyQueue(string name);
}
public class AzureServiceBusQueueFactory : IMessageQueueFactory
{
      IMessageQueue CreateOutboundQueue(string name)
      {
           //init queue
           return new AzureMessageQueue(/*....*/);
      }
      IMessageQueue CreateReplyQueue(string name)
      {
           //init response queue
           return new AzureResponseMessageQueue(/*....*/);
      }
}
public class MsmqFactory : IMessageQueueFactory
{
      IMessageQueue CreateOutboundQueue(string name)
      {
           //init queue
           return new MsmqMessageQueue(/*....*/);
      }
      IMessageQueue CreateReplyQueue(string name)
      {
           //init response queue
           return new MsmqResponseMessageQueue(/*....*/);
      }
}

Fabrieksmethode

Het probleem bij HTTP-servers is dat we altijd een reactie nodig hebben voor elk verzoek.

public interface IHttpRequest
{
    // .. all other methods ..
    IHttpResponse CreateResponse(int httpStatusCode);
}

Zonder de fabrieksmethode zouden de HTTP-servergebruikers (d.w.z. programmeurs) worden gedwongen om implementatiespecifieke klassen te gebruiken die het doel van de IHttpRequest-interface tenietdoen.

Daarom introduceren we de fabrieksmethode, zodat het maken van de responsklasse ook wordt weggeabstraheerd.

Samenvatting

Het verschil is dat het beoogde doelvan de klasse die een fabrieksmethode bevat niet is om objecten te maken, terwijl een abstracte fabriek alleen moet worden gebruikt om objecten te maken.

Je moet voorzichtig zijn bij het gebruik van fabrieksmethoden, aangezien het gemakkelijk is om de LSP te doorbreken (Liskov-substitutieprincipe) bij het maken van objecten.

Antwoord 3, autoriteit 21%

Het verschil tussen de ontwerppatronen van AbstractFactory en Factory is als volgt:

• Fabrieksmethodewordt gebruikt om slechts één product te maken, maar Abstract Factorygaat over het maken van families van gerelateerde of afhankelijke producten.
• Fabrieksmethodepatroon onthult een methode voor de klant om het object te maken, terwijl in het geval van Abstract Factoryze een familie van gerelateerde objecten blootleggen die uit deze Factory kunnen bestaan methoden.
• Fabrieksmethodepatroon verbergt de constructie van een enkel object, terwijl Abstracte fabriekde constructie van een familie van verwante objecten verbergt. Abstracte fabrieken worden meestal geïmplementeerd met behulp van (een reeks) fabrieksmethoden.
• Abstract Factory-patroon gebruikt compositie om de verantwoordelijkheid voor het maken van een object aan een andere klasse te delegeren, terwijl het Factory Method-ontwerppatroon gebruikmaakt van overerving en vertrouwt op een afgeleide klasse of subklasse om te creëren een object.
• Het idee achter het Factory Method-patroon is dat het het geval mogelijk maakt waarin een klant niet weet welke concrete klassen hij tijdens runtime moet maken, maar gewoon een klasse wil krijgen dat zal het werk doen, terwijl het Abstract Factory-patroon het best wordt gebruikt wanneer uw systeem meerdere productfamilies moet maken of als u een bibliotheek met producten wilt bieden zonder de implementatiedetails bloot te leggen.!

Implementatie van patroon van fabrieksmethode:

Abstracte fabriekspatroonimplementatie:

Antwoord 4, autoriteit 9%

Het belangrijkste verschil tussen Abstract Factory en Factory Method is dat Abstract Factory wordt geïmplementeerd door Composition; maar Fabrieksmethode wordt geïmplementeerd door Inheritance.

Ja, je leest het goed: het belangrijkste verschil tussen deze twee patronen is de oude compositie versus overervingdebat.

UML-diagrammen zijn te vinden in het (GoF) boek. Ik wil codevoorbeelden geven, omdat ik denk dat het combineren van de voorbeelden uit de bovenste twee antwoorden in deze thread een betere demonstratie zal geven dan elk antwoord alleen. Daarnaast heb ik terminologie uit het boek gebruikt in klassen- en methodenamen.

Abstracte fabriek

1. Het belangrijkste om hier te begrijpen is dat de abstracte fabriek
   wordt geïnjecteerdin de client. Dit is waarom we zeggen dat Abstract
   Factory wordt geïmplementeerd door Composition. Vaak een afhankelijkheidsinjectie
   kader zou die taak uitvoeren; maar een kader is niet vereist
   voor DI.
2. Het tweede kritieke punt is dat de betonfabrieken hier zijn
   nietFactory Method-implementaties! Voorbeeldcode voor Fabriek
   De methode wordt hieronder weergegeven.
3. En tot slot, het derde punt om op te merken is de relatie tussen de
   producten: in dit geval de uitgaande en antwoordwachtrijen. een concrete
   fabriek produceert Azure-wachtrijen, de andere MSMQ. De GoF verwijst naar:
   deze productrelatie als een “familie” en het is belangrijk om te zijn
   besef dat familie in dit geval geen klassenhiërarchie betekent.

public class Client {
    private final AbstractFactory_MessageQueue factory;
    public Client(AbstractFactory_MessageQueue factory) {
        // The factory creates message queues either for Azure or MSMQ.
        // The client does not know which technology is used.
        this.factory = factory;
    }
    public void sendMessage() {
        //The client doesn't know whether the OutboundQueue is Azure or MSMQ.
        OutboundQueue out = factory.createProductA();
        out.sendMessage("Hello Abstract Factory!");
    }
    public String receiveMessage() {
        //The client doesn't know whether the ReplyQueue is Azure or MSMQ.
        ReplyQueue in = factory.createProductB();
        return in.receiveMessage();
    }
}
public interface AbstractFactory_MessageQueue {
    OutboundQueue createProductA();
    ReplyQueue createProductB();
}
public class ConcreteFactory_Azure implements AbstractFactory_MessageQueue {
    @Override
    public OutboundQueue createProductA() {
        return new AzureMessageQueue();
    }
    @Override
    public ReplyQueue createProductB() {
        return new AzureResponseMessageQueue();
    }
}
public class ConcreteFactory_Msmq implements AbstractFactory_MessageQueue {
    @Override
    public OutboundQueue createProductA() {
        return new MsmqMessageQueue();
    }
    @Override
    public ReplyQueue createProductB() {
        return new MsmqResponseMessageQueue();
    }
}

fabrieksmethode

1. Het belangrijkste punt om hier te grijpen is dat de ConcreteCreator
   is de klant. Met andere woorden, de klant is een subklasse waarvan de ouder de factoryMethod()definieert. Dit is waarom we dat zeggen
   Fabrieksmethode wordt geïmplementeerd door erfenis.
2. Het tweede kritieke punt is om te onthouden dat de fabrieksmethode
   Patroon is niets meer dan een specialisatie van de sjabloonmethode
   Patroon. De twee patronen delen een identieke structuur. Alleen zij
   verschillen in doel. Fabrieksmethode is Creational (het bouwt
   iets) terwijl sjabloonmethode gedrag is (het berekent
   iets).
3. en ten slotte is het derde punt om op te merken dat de Creator(ouder)
   Klasse roept zijn eigen factoryMethod(). Als we verwijderen
   anOperation()van de ouderklasse, en laat slechts één enkele methode achter
   Achter, het is niet langer het fabrieksmethodepatroon. Met andere woorden,
   Fabrieksmethode kan niet worden geïmplementeerd met minder dan twee methoden in
   de ouderklasse; en men moet de ander oproepen.

public abstract class Creator {
    public void anOperation() {
        Product p = factoryMethod();
        p.whatever();
    }
    protected abstract Product factoryMethod();
}
public class ConcreteCreator extends Creator {
    @Override
    protected Product factoryMethod() {
        return new ConcreteProduct();
    }
}

misc. & AMP; Sundriemen fabriekspatronen

Houd er rekening mee dat hoewel de GoF twee verschillende fabriekspatronen definieert, dit niet de enige bestaande fabriekspatronen zijn. Het zijn niet eens noodzakelijk de meest gebruikte fabriekspatronen. Een beroemd derde voorbeeld is het Static Factory Pattern van Josh Bloch van Effective Java. Het Head First Design Patterns-boek bevat nog een ander patroon dat ze Simple Factory noemen.

Val niet in de valkuil om aan te nemen dat elk fabriekspatroon moet overeenkomen met een patroon van de GoF.

Antwoord 5, autoriteit 6%

Abstract Factory is een interface voor het maken van gerelateerde producten, maar Factory Method is slechts één methode. Abstracte fabriek kan worden geïmplementeerd door meerdere fabrieksmethoden.

Antwoord 6, autoriteit 2%

Beschouw dit voorbeeld voor een beter begrip.

Wat bieden telecommunicatiebedrijven? Breedband, telefoonlijn en mobiel bijvoorbeeld en je wordt gevraagd een applicatie te maken om hun producten aan hun klanten aan te bieden.

Over het algemeen zou je hier de producten maken, dwz breedband, telefoonlijn en mobiel, via je fabrieksmethode, waarbij je weet welke eigenschappen je hebt voor die producten en het is vrij eenvoudig.

Nu wil het bedrijf hun klanten een bundel van hun producten aanbieden, d.w.z. breedband, telefoonlijn en mobiel samen, en hier komt de Abstract Factoryom te spelen.

Abstract Factoryis, met andere woorden, de samenstelling van andere fabrieken die verantwoordelijk zijn voor het maken van hun eigen producten en Abstract Factoryweet deze producten in meer zinvol met betrekking tot zijn eigen verantwoordelijkheden.

In dit geval is de BundleFactoryde Abstracte Fabriek, BroadbandFactory, PhonelineFactoryen MobileFactoryzijn de Factory. Om meer te vereenvoudigen, hebben deze fabrieken een fabrieksmethodeom de afzonderlijke producten te initialiseren.

Zie het codevoorbeeld hieronder:

public class BroadbandFactory : IFactory {
    public static Broadband CreateStandardInstance() {
        // broadband product creation logic goes here
    }
}
public class PhonelineFactory : IFactory {
    public static Phoneline CreateStandardInstance() {
        // phoneline product creation logic goes here
    }
}
public class MobileFactory : IFactory {
    public static Mobile CreateStandardInstance() {
        // mobile product creation logic goes here
    }
}
public class BundleFactory : IAbstractFactory {
    public static Bundle CreateBundle() {
        broadband = BroadbandFactory.CreateStandardInstance();
        phoneline = PhonelineFactory.CreateStandardInstance();
        mobile = MobileFactory.CreateStandardInstance();
        applySomeDiscountOrWhatever(broadband, phoneline, mobile);
    }
    private static void applySomeDiscountOrWhatever(Broadband bb, Phoneline pl, Mobile m) {
        // some logic here
        // maybe manange some variables and invoke some other methods/services/etc.
    }
}

Hopelijk helpt dit.

7

Real Life Voorbeeld. (Gemakkelijk te onthouden)

fabriek

Stel je voor dat je een huis bouwt en je een timmerman voor een deur benadert. U geeft de meting voor de deur en uw vereisten, en hij zal een deur voor u construeren. In dit geval is de timmerman een fabriek van deuren. Uw specificaties zijn ingangen voor de fabriek en de deur is de uitvoer of het product uit de fabriek.

Abstracte fabriek

Overweeg nu hetzelfde voorbeeld van de deur. Je kunt naar een timmerman, of je kunt naar een plastic deurwinkel of een PVC-winkel. Ze zijn allemaal deurfabrieken. Op basis van de situatie bepaalt u wat voor soort fabriek u nodig hebt om te benaderen. Dit is als een abstracte fabriek.

Ik heb hier uitgelegd, zowel fabrieksmethodepatroon als abstracte fabriekspatroon beginnend met het niet gebruiken van het verklaren van problemen en het oplossen van problemen met behulp van de bovenstaande patronen
https://github.com/vikramnagineni/design-patterns/tree/master

8

Begrijp de verschillen in de motivaties:

Stel dat u een gereedschap brengt waar u objecten en een concrete implementatie van de onderdelen van de objecten hebt. Aangezien u variaties in de objecten voorziet, hebt u een indirection aangemaakt door de verantwoordelijkheid toe te wijzen voor het maken van varianten van de objecten aan een ander object (noemen we het abstracte fabriek ). Deze abstractie vindt een sterk voordeel, omdat u toekomstige uitbreidingen voorgevallen die varianten van die objecten nodig hebben.

Een andere nogal intrigerende motivatie in deze lijn van gedachten is een geval waarin elke of-geen van de objecten uit de hele groep een overeenkomstige variant zullen hebben. Op basis van sommige omstandigheden zal een van de varianten worden gebruikt en in elk geval moeten alle objecten van dezelfde variant zijn. Dit kan een beetje intuïtief zijn om te begrijpen omdat we vaak denken dat – zolang de varianten van een object een gemeenschappelijk uniformontvang (-interface in bredere zin ) volgen, moet de concrete implementatiecode nooit breken . Het intrigerende feit hier is dat, niet altijd dit geldt, vooral wanneer het verwachte gedrag niet kan worden gemodelleerd door een programmeercontract.

Een eenvoudige (Lenen van het idee van GOF ) Zeggen elke GUI-applicaties een virtuele monitor die het zien van een gevoel van MS of MAC of Fedora OS’s emuleert. Hier bijvoorbeeld wanneer alle widgetobjecten zoals venster, knop, enz. MS-variant hebben, behalve een scroll-balk die is afgeleid van MAC-variant, faalt het doel van het gereedschap slecht.

Deze bovenstaande gevallen vormen de fundamentele behoefte van abstract fabriekspatroon .

Aan de andere kant, stel je voor dat je een raamwerk schrijft, zodat veel mensen verschillende gereedschappen (zoals die van bovenstaande voorbeelden ) kunnen opgebouwd, met behulp van je kader. Door het enig idee van een raamwerk hoeft u het niet, zij het niet kunt gebruiken met concrete objecten in uw logica. Je legt liever wat op hoog niveau contracten tussen verschillende objecten en hoe ze communiceren. Terwijl u (als een kaderontwikkelaar ) op een zeer abstract niveau blijft, worden elke bouwers van het gereedschap gedwongen om uw kaderconstructen te volgen. Zij (De gereedschapsbouwers ) hebben echter de vrijheid om te beslissen welk object wordt gebouwd en hoe alle objecten die zij creëren, zullen communiceren. In tegenstelling tot het vorige geval (van abstracte fabriekspatroon hoeft u (als raamwerkschepper ) in dit geval niet met concrete objecten te werken; en kan eerder op het contractniveau van de objecten blijven. Verder, in tegenstelling tot het tweede deel van de eerdere motivaties, hebben u of de tool-builders nooit de situatie van het mengen van objecten van varianten. Hier, terwijl kadercode op contractniveau blijft, is elke tool-builder beperkt (door de aard van het geval zelf ) om hun eigen objecten te gebruiken. Objectcreaties in dit geval worden gedelegeerd aan elke implementator- en kaderaanbieders bieden alleen uniforme methoden voor het maken en retourneren van objecten. Dergelijke methoden zijn onvermijdelijk voor raamwerkontwikkelaar om door te gaan met hun code en heeft een speciale naam genaamd fabrieksmethode (fabrieksmethode patroon voor het onderliggende patroon ).

Enkele opmerkingen:

• Als je bekend bent met ‘sjabloonmethode’, dan zou je zien dat fabrieksmethoden vaak worden aangeroepen vanuit sjabloonmethoden in het geval van programma’s die betrekking hebben op elke vorm van raamwerk. Daarentegen zijn sjabloonmethoden van applicatieprogramma’s vaak een eenvoudige implementatie van een specifiek algoritme en vervallen fabrieksmethoden.
• Bovendien, voor de volledigheid van de gedachten, met behulp van het raamwerk (hierboven vermeld), wanneer een gereedschapsbouwer een gereedschap bouwt, binnen elke fabrieksmethode, in plaats van een concreet object te maken, hij /zij kan de verantwoordelijkheid verder delegeren aan een abstract fabrieksobject, op voorwaarde dat de gereedschapsbouwer variaties van de concrete objecten voorziet voor toekomstige uitbreidingen.

Voorbeeldcode:

//Part of framework-code
BoardGame {
    Board createBoard() //factory method. Default implementation can be provided as well
    Piece createPiece() //factory method
    startGame(){        //template method
         Board borad = createBoard()
         Piece piece = createPiece()
         initState(board, piece)
    }
}
//Part of Tool-builder code
Ludo inherits  BoardGame {
     Board createBoard(){ //overriding of factory method
         //Option A: return new LudoBoard() //Lodu knows object creation
         //Option B: return LudoFactory.createBoard() //Lodu asks AbstractFacory
     }
….
}
//Part of Tool-builder code
Chess inherits  BoardGame {
    Board createBoard(){ //overriding of factory method
        //return a Chess board
    }
    ….
}

Antwoord 9

1. Mijn eerste vraag gaat over de abstracte fabriek. Is het zijn rol om u in staat te stellen families van concrete objecten te maken (dat kan afhangen van de specifieke fabriek die u gebruikt) in plaats van slechts een enkel concreet object?

JA. De intentie van abstracte fabriek is:

Geef een interface voor het maken van families van gerelateerde of afhankelijke objecten zonder hun betonnen klassen op te geven.

2. retourneert de abstracte fabriek slechts één zeer groot object of veel objecten, afhankelijk van welke methoden u belt?

Idealiter zou het een object per de methode-client moeten retourneren.

3. Mijn begrip is dat het fabrieksmethodepatroon een maker-interface heeft die de Concretecreator zal maken die verantwoordelijk is voor het weten welk betonproduct om te instantiëren. Is dit wat het betekent met het gebruik van overerving om objectinstantie te verwerken?

JA. Fabrieksmethode gebruikt erfenis.

4. Abstract fabriekspatroon Delegeren de verantwoordelijkheid van Object Instantiation aan een ander object via compositie? Wat betekent dit?

AbstractFactory definieert een fabrieksmethod en Concretefactory is verantwoordelijk voor het bouwen van een betonproduct. Volg gewoon door het CODE-voorbeeld in deze artikel .

U kunt meer details vinden in Related SE-berichten:

Wat Is het basisverschil tussen de fabrieks- en abstracte fabriekspatronen?

Ontwerppatronen: Fabriek Vs Factory Method vs abstracte fabriek

10

Laten we duidelijk maken dat we in productiecode meestal een abstract fabriekspatroon gebruiken omdat klasse A is geprogrammeerd met interface B. En A moet instanties van B maken. Dus A moet een fabrieksobject hebben om te produceren exemplaren van B. Dus A is niet afhankelijk van een concreet exemplaar van B. Ik hoop dat het helpt.

Antwoord 11

Om het heel eenvoudig te maken met minimale interface & focus alstublieft “//1”:

class FactoryProgram
    {
        static void Main()
        {
            object myType = Program.MyFactory("byte");
            Console.WriteLine(myType.GetType().Name);
            myType = Program.MyFactory("float"); //3
            Console.WriteLine(myType.GetType().Name);
            Console.ReadKey();
        }
        static object MyFactory(string typeName)
        {
            object desiredType = null; //1
            switch (typeName)
            {
                case "byte": desiredType = new System.Byte(); break; //2
                case "long": desiredType = new System.Int64(); break;
                case "float": desiredType = new System.Single(); break;
                default: throw new System.NotImplementedException();
            }
            return desiredType;
        }
    }

Hier belangrijke punten: 1. Fabriek & AbstractFactory-mechanismen moeten overerving gebruiken (System.Object-> byte, float …); dus als je overerving hebt in het programma, dan is Factory (Abstract Factory zou er hoogstwaarschijnlijk niet zijn) er al door ontwerp 2. Creator (MyFactory) kent het concrete type, dus retourneert een concreet type-object naar de beller (Main); In abstracto zou fabrieksretour een Interface zijn.

interface IVehicle { string VehicleName { get; set; } }
interface IVehicleFactory
    {
        IVehicle CreateSingleVehicle(string vehicleType);
    }
class HondaFactory : IVehicleFactory
    {
        public IVehicle CreateSingleVehicle(string vehicleType)
        {
            switch (vehicleType)
            {
                case "Sports": return new SportsBike();
                case "Regular":return new RegularBike();
                default: throw new ApplicationException(string.Format("Vehicle '{0}' cannot be created", vehicleType));
            }
        }
    }
class HeroFactory : IVehicleFactory
    {
        public IVehicle CreateSingleVehicle(string vehicleType)
        {
            switch (vehicleType)
            {
                case "Sports":  return new SportsBike();
                case "Scooty": return new Scooty();
                case "DarkHorse":return new DarkHorseBike();
                default: throw new ApplicationException(string.Format("Vehicle '{0}' cannot be created", vehicleType));
            }
        }
    }
class RegularBike : IVehicle { public string VehicleName { get { return "Regular Bike- Name"; } set { VehicleName = value; } } }
class SportsBike : IVehicle { public string VehicleName { get { return "Sports Bike- Name"; } set { VehicleName = value; } } }
class RegularScooter : IVehicle { public string VehicleName { get { return "Regular Scooter- Name"; } set { VehicleName = value; } } }
class Scooty : IVehicle { public string VehicleName { get { return "Scooty- Name"; } set { VehicleName = value; } } }
class DarkHorseBike : IVehicle { public string VehicleName { get { return "DarkHorse Bike- Name"; } set { VehicleName = value; } } }
class Program
{
    static void Main(string[] args)
    {
        IVehicleFactory honda = new HondaFactory(); //1
        RegularBike hondaRegularBike = (RegularBike)honda.CreateSingleVehicle("Regular"); //2
        SportsBike hondaSportsBike = (SportsBike)honda.CreateSingleVehicle("Sports");
        Console.WriteLine("******* Honda **********"+hondaRegularBike.VehicleName+ hondaSportsBike.VehicleName);
        IVehicleFactory hero = new HeroFactory();
        DarkHorseBike heroDarkHorseBike = (DarkHorseBike)hero.CreateSingleVehicle("DarkHorse");
        SportsBike heroSportsBike = (SportsBike)hero.CreateSingleVehicle("Sports");
        Scooty heroScooty = (Scooty)hero.CreateSingleVehicle("Scooty");
        Console.WriteLine("******* Hero **********"+heroDarkHorseBike.VehicleName + heroScooty.VehicleName+ heroSportsBike.VehicleName);
        Console.ReadKey();
    }
}

Belangrijke punten: 1. Vereiste: Honda zou “gewone”, “sporten” creëren, maar held zou “DarkHorse”, “Sports” en “Scooty” creëren. 2. Waarom twee interfaces? Één voor fabrikantstype (ivehiclefactory) en een andere voor productfabriek (Ivehicle); Andere manier om 2 interfaces te begrijpen is abstracte fabriek draait om het creëren van gerelateerde objecten 2. De vangst is de kinderen van ivehiclefactory die terugkeert en ivehicle (in plaats van beton in fabriek); Dus ik krijg bovenliggende variabele (ivehicle); Dan maak ik het daadwerkelijke betontype door CreatresSingleVehicle te bellen en het ouderobject te gieten op het echte kinderobject. Wat zou er gebeuren als ik het doe RegularBike heroRegularBike = (RegularBike)hero.CreateSingleVehicle("Regular");; Je krijgt applicatieexception en daarom hebben we een generieke abstracte fabriek nodig die ik zou uitleggen indien nodig. Ik hoop dat het helpt bij het beginneling tot het intermediair publiek.

12

Ik zou op elk moment de voorkeur geven aan Abstract Factory boven Factory Method. Uit het voorbeeld van Tom Dalling (goede uitleg trouwens) hierboven, kunnen we zien dat Abstract Factory beter samen te stellen is, omdat we alleen een andere Factory aan de constructor hoeven door te geven (injectie van constructorafhankelijkheid die hier wordt gebruikt). Maar Factory Method vereist dat we een nieuwe klasse introduceren (meer dingen om te beheren) en subklassen gebruiken. Geef altijd de voorkeur aan compositie boven overerving.

Antwoord 13

Abstracte fabriek: een fabriek van fabrieken; een fabriek die de individuele maar verwante/afhankelijke fabrieken groepeert zonder hun concrete klassen te specificeren.
Abstract fabrieksvoorbeeld

Fabriek: het biedt een manier om de instantiatielogica te delegeren aan onderliggende klassen.
Voorbeeld fabriekspatroon

Antwoord 14

Er zijn nogal wat definities. De drie gebruikelijke manieren om fabriekspatroonte beschrijven zijn:

1. Eenvoudige Fabriek

Eenvoudige methode/klasse voor het maken van objecten op basis van een voorwaarde.

2. Fabrieksmethode

Het ontwerppatroon van de Factory Method dat subklassen gebruikt om de implementatie te bieden.

3. Abstracte fabriek

Het ontwerppatroon van de Abstracte Fabriek produceert families van verwante of afhankelijke objecten zonder hun concrete klassen te specificeren.

De onderstaande link was erg handig – fabrieksvergelijking – refactoring.guru

15

Veel van de vorige antwoorden bieden geen codevergelijkingen tussen abstracte fabrieks- en fabrieksmethodepatroon. Het volgende is mijn poging om het via Java uit te leggen. Ik hoop dat het iemand helpt een eenvoudige verklaring te hebben.

As gof zegt aptly: abstracte fabriek biedt een interface voor het creëren van families van gerelateerde of afhankelijke objecten zonder opgeven
hun betonnen klassen.

public class Client {
    public static void main(String[] args) {
        ZooFactory zooFactory = new HerbivoreZooFactory();
        Animal animal1 = zooFactory.animal1();
        Animal animal2 = zooFactory.animal2();
        animal1.sound();
        animal2.sound();
        System.out.println();
        AnimalFactory animalFactory = new CowAnimalFactory();
        Animal animal = animalFactory.createAnimal();
        animal.sound();
    }
}

public interface Animal {
    public void sound();
}
public class Cow implements Animal {
    @Override
    public void sound() {
        System.out.println("Cow moos");
    }
}
public class Deer implements Animal {
    @Override
    public void sound() {
        System.out.println("Deer grunts");
    }
}
public class Hyena implements Animal {
    @Override
    public void sound() {
        System.out.println("Hyena.java");
    }
}
public class Lion implements Animal {
    @Override
    public void sound() {
        System.out.println("Lion roars");
    }
}

public interface ZooFactory {
    Animal animal1();
    Animal animal2();
}
public class CarnivoreZooFactory implements ZooFactory {
    @Override
    public Animal animal1() {
        return new Lion();
    }
    @Override
    public Animal animal2() {
        return new Hyena();
    }
}
public class HerbivoreZooFactory implements ZooFactory {
    @Override
    public Animal animal1() {
        return new Cow();
    }
    @Override
    public Animal animal2() {
        return new Deer();
    }
}

public interface AnimalFactory {
    public Animal createAnimal();
}
public class CowAnimalFactory implements AnimalFactory {
    @Override
    public Animal createAnimal() {
        return new Cow();
    }
}
public class DeerAnimalFactory implements AnimalFactory {
    @Override
    public Animal createAnimal() {
        return new Deer();
    }
}
public class HyenaAnimalFactory implements AnimalFactory {
    @Override
    public Animal createAnimal() {
        return new Hyena();
    }
}
public class LionAnimalFactory implements AnimalFactory {
    @Override
    public Animal createAnimal() {
        return new Lion();
    }
}

Antwoord 16

abstract fabrieksontwerppatroon met realtime voorbeeld: wat is een abstract fabrieksontwerppatroon? Het is vergelijkbaar met het ontwerppatroon van de fabrieksmethode. we moeten dit patroon gebruiken als we meerdere fabrieken hebben. er zal een groepering van fabrieken zijn gedefinieerd in dit patroon. fabrieksmethodepatroon is een subset van abstract fabrieksontwerppatroon. Ze hebben dezelfde voordelen als fabriekspatronen. abstracte fabriek vertrouwt op objectsamenstelling, terwijl de fabrieksmethode zich bezighoudt met overerving.
fabrieksontwerppatroon in java met een realtime voorbeeld: wat is het fabrieksontwerppatroon? het wordt meestal gebruikt ontwerp in objectgeoriënteerd programmeren. Het is een van de scheppingspatronen. het gaat allemaal om het maken van instanties. Clients zullen het object maken zonder blootgesteld te worden aan logica voor het maken van objecten. het wordt veel gebruikt in verschillende kaders, bijvoorbeeld: het veerkader. we gebruiken dit patroon wanneer de klasse de objecten van een andere klasse niet kent die hij moet maken.
Realtime voorbeeld: wanneer onze auto onderweg kapot gaat. We moeten de reparateur informeren over het type voertuig dat we gebruiken, zodat de reparateur gereedschap bij zich heeft om de reparatie te repareren. volgens onze input zal de reparateur het probleem oplossen en het klaar maken voor ons om weer te reizen.
Er zijn een paar ingebouwde methoden die deze patronen gebruiken. voorbeeld getInstance() methode in JavaUtilcalendar klasse. Met behulp van getInstance() kunnen we objecten krijgen wanneer we deze methode uitvoeren.
Javautilcalendar : getInstance() is een methoderetourobject.
https://trendydevx.com/factory-design-pattern -in-java-met-realtime-voorbeeld/