Entwurfsmuster: Abstrakte Fabrik gegen Fabrikmethode

Hinweis: Fragen finden Sie am Ende des Beitrags.

Ich habe die anderen Stackoverflow-Threads zu Abstract Factory vs Factory Method gelesen . Ich verstehe die Absicht jedes Musters. Die Definition ist mir jedoch nicht klar.

Die Factory-Methode definiert eine Schnittstelle zum Erstellen eines Objekts, lässt jedoch Unterklassen entscheiden, welche davon instanziiert werden sollen. Mit einer Factory-Methode können Klassen die Instanziierung auf Unterklassen verschieben.

Im Gegensatz dazu bietet eine abstrakte Factory eine Schnittstelle zum Erstellen von Familien verwandter oder abhängiger Objekte, ohne deren konkrete Klassen anzugeben.

- John Feminella

Die Abstract Factory sieht der Factory-Methode sehr ähnlich . Ich habe einige UML-Klassen gezeichnet, um meinen Standpunkt zu veranschaulichen.

Hinweis:

• Das Diagramm stammt von www.yuml.com und ist daher nicht perfekt ausgerichtet. Aber es ist ein kostenloser Service :).
• Die Diagramme sind möglicherweise nicht perfekt. Ich lerne immer noch die GoF- Designmuster.

Fabrikmethode:

Abstrakte Fabrik (nur 1 Mitglied):

Abstract Factory (weitere Mitglieder):

Fragen:

1. Wenn die Abstract Factory nur einen Schöpfer und ein Produkt hat, ist es dann immer noch das Abstract Factory- Muster? (eine Schnittstelle zum Erstellen von Familien)
2. Kann der konkrete Ersteller der Factory-Methode aus einer Schnittstelle erstellt werden oder muss er aus einer Klasse stammen? (Klassen verschieben Instanziierungen auf Unterklassen)
3. Wenn die Abstract Factory nur einen Ersteller und ein Produkt haben kann, besteht der einzige Unterschied zwischen der Abstract Factory und der Factory-Methode darin, dass der Ersteller für die erstere eine Schnittstelle und der Ersteller für die letztere eine Klasse ist?

Hoffe das hilft. Es beschreibt die verschiedenen Arten von Fabriken. Ich habe Head First Design Patterns als Referenz verwendet. Ich habe yuml.me zum Zeichnen verwendet .

Statische Fabrik

Ist eine Klasse mit einer statischen Methode zum Produzieren verschiedener Untertypen von Produkten.

Einfache Fabrik

Ist eine Klasse, die verschiedene Untertypen von Produkten erzeugen kann. (Es ist besser als die Static Factory. Wenn neue Typen hinzugefügt werden, muss die Basisproduktklasse nicht nur in der Simple Factory-Klasse geändert werden.)

Fabrikmethode

Enthält eine Methode zur Herstellung eines Produkttyps, der mit seinem Typ zusammenhängt. (Es ist besser als eine einfache Fabrik, da der Typ auf eine Unterklasse verschoben wird.)

Abstrakte Fabrik

Erzeugt eine Familie von verwandten Typen. Es unterscheidet sich deutlich von einer Factory-Methode, da es mehr als eine Art von Typen gibt, die es erzeugt. (Dies ist kompliziert. Weitere Informationen finden Sie im nächsten Diagramm.)

Beispiel aus dem .NET Framework

DbFactoriesProvider ist eine einfache Factory, da es keine Untertypen gibt. Der DbFactoryProvider ist eine abstrakte Factory, da er verschiedene verwandte Datenbankobjekte wie Verbindungs- und Befehlsobjekte erstellen kann.

.

Die beiden Muster sind sicherlich verwandt!

Der Unterschied zwischen Mustern ist im Allgemeinen beabsichtigt.

Die Absicht der Factory-Methode ist "Definieren Sie eine Schnittstelle zum Erstellen eines Objekts, aber lassen Sie Unterklassen entscheiden, welche Klasse instanziiert werden soll. Mit der Factory-Methode kann eine Klasse die Instanziierung auf Unterklassen verschieben."

Die Absicht von Abstract Factory ist, "eine Schnittstelle zum Erstellen von Familien verwandter oder abhängiger Objekte bereitzustellen, ohne deren konkrete Klassen anzugeben."

Basierend auf diesen Absichtserklärungen (zitiert von GoF) würde ich sagen, dass die Factory-Methode in gewissem Sinne eine "entartete" abstrakte Factory mit einer Familie von einer ist.

Sie unterscheiden sich im Allgemeinen in der Implementierung, da die Factory-Methode viel einfacher ist als die Abstract Factory .

Sie sind jedoch auch in der Umsetzung verwandt. Wie im GoF-Buch erwähnt,

AbstractFactory deklariert nur eine Schnittstelle zum Erstellen von Produkten. Es liegt an den ConcreteProduct-Unterklassen, diese tatsächlich zu erstellen. Der häufigste Weg, dies zu tun, besteht darin, für jedes Produkt eine Fabrikmethode zu definieren.

Dieses c2-Wiki bietet auch einige interessante Diskussionen zu diesem Thema.

Es scheint, dass die Liste der (ausgezeichneten) Fragen des OP ignoriert wurde. Aktuelle Antworten bieten lediglich überarbeitete Definitionen. Deshalb werde ich versuchen, die ursprünglichen Fragen kurz zu beantworten.

1. Wenn die Abstract Factory nur einen Schöpfer und ein Produkt hat, ist es dann immer noch das Abstract Factory- Muster? (eine Schnittstelle zum Erstellen von Familien)

Nein . Eine abstrakte Fabrik muss mehr als ein Produkt erstellen, um eine "Familie verwandter Produkte" zu erstellen. Das kanonische GoF-Beispiel erstellt ScrollBar()und Window(). Der Vorteil (und Zweck) besteht darin, dass die Abstract Factory ein gemeinsames Thema für mehrere Produkte durchsetzen kann.

2. Kann der konkrete Ersteller der Factory-Methode aus einer Schnittstelle erstellt werden oder muss er aus einer Klasse stammen? (Klassen verschieben Instanziierungen auf Unterklassen)

Zunächst müssen wir beachten, dass weder Java noch C # existierten, als die GoF ihr Buch schrieb. Die GoF-Verwendung des Begriffs Schnittstelle hängt nicht mit den Schnittstellentypen zusammen, die von bestimmten Sprachen eingeführt werden. Daher kann der konkrete Ersteller aus einer beliebigen API erstellt werden. Der wichtige Punkt im Muster ist, dass die API ihre eigene Factory-Methode verwendet, sodass eine Schnittstelle mit nur einer Methode nicht mehr eine Factory-Methode sein kann als eine Abstract Factory.

3. Wenn die Abstract Factory nur einen Ersteller und ein Produkt haben kann, besteht der einzige Unterschied zwischen der Abstract Factory und der Factory-Methode darin, dass der Ersteller für die erstere eine Schnittstelle und der Ersteller für die letztere eine Klasse ist?

Diese Frage ist nach den obigen Antworten nicht mehr gültig. Wenn Sie jedoch der Meinung sind, dass der einzige Unterschied zwischen Abstract Factory und Factory Method in der Anzahl der erstellten Produkte besteht, sollten Sie überlegen, wie ein Kunde jedes dieser Muster verwendet. Eine Abstract Factory wird normalerweise in ihren Client eingefügt und über Komposition / Delegierung aufgerufen. Eine Factory-Methode muss vererbt werden. Es kommt also alles auf die alte Debatte zwischen Komposition und Erbschaft zurück.

Aber diese Antworten haben eine vierte Frage aufgeworfen!

4. Da eine Schnittstelle mit nur einer Methode nicht mehr eine Factory-Methode als eine abstrakte Factory sein kann , wie nennen wir eine kreative Schnittstelle mit nur einer Methode?

Wenn die Methode statisch ist, wird sie üblicherweise als statische Factory bezeichnet . Wenn die Methode nicht statisch ist, wird sie üblicherweise als Simple Factory bezeichnet . Keines davon ist ein GoF-Muster, aber in der Praxis werden sie weitaus häufiger verwendet!

Meiner Meinung nach liegt der geringfügige Unterschied zwischen den beiden Mustern in der Anwendbarkeit und damit, wie bereits gesagt, in der Absicht .

Lassen Sie uns die Definitionen zusammenfassen (beide aus Wikipedia).

Abstrakte Fabrik

Stellen Sie eine Schnittstelle zum Erstellen von Familien verwandter oder abhängiger Objekte bereit , ohne deren konkrete Klassen anzugeben.

Fabrikmethode

Definieren Sie eine Schnittstelle zum Erstellen eines Objekts , aber lassen Sie die Klassen, die die Schnittstelle implementieren, entscheiden, welche Klasse instanziiert werden soll . Mit der Factory-Methode kann eine Klasse die Instanziierung auf Unterklassen verschieben.

Mit beiden Mustern können die Benutzerobjekte von der Erstellung der erforderlichen Instanzen entkoppelt werden (Laufzeitentkopplung). Dies ist der gemeinsame Aspekt. Beide Muster ermöglichen es, eine Hierarchie von Fabriken entsprechend den spezifischen Anforderungen zu erstellen, und dies ist ein weiterer gemeinsamer Aspekt.

Abstract Factory ermöglicht es, mehrere verschiedene Arten von Instanzen in einer Unterklasse zu erstellen und das Erstellungsverhalten in den verschiedenen Unterklassen zu spezifizieren. Normalerweise deklariert die Factory-Methode die Erstellung nur eines Objekttyps, der gemäß dem Unterklassifizierungsmechanismus spezifiziert werden kann. Das ist der Unterschied.

Durch Zusammenfassung. Angenommen, Product definiert die Superklasse der erstellenden Objekte und ProductA und ProductB sind zwei verschiedene Unterklassen. Daher verfügt die Abstract Factory-Methode über zwei Methoden, createProductA () und createProductB (), die (in Bezug auf Erstellungsschritte) in ihren spezifischen Unterklassen spezifiziert werden: Die Factory-Unterklassen spezifizieren die Erstellungsschritte für die beiden definierten Klassen von Objekten in der Schöpfung.

Gemäß dem obigen Beispiel wird die Factory-Methode unterschiedlich implementiert, wobei die Erstellung von ProductA und ProductB in möglichst vielen Fabriken abstrahiert wird (eine Methode pro Factory), und die weitere Spezialisierung der Erstellungsschritte wird an die Hierarchie delegiert, während sie erstellt wird .

Wenn ich eine abstrahierte Factory-Klasse (auf die über eine Schnittstelle oder eine abstrakte Basisklasse verwiesen wird) erstellt habe, die Objekte erstellt, die nur eine Methode zum Erstellen von Objekten haben, wäre dies eine Factory-Methode .

Wenn die abstrahierte Factory mehr als eine Methode zum Erstellen von Objekten hätte, wäre sie eine abstrakte Factory .

Angenommen, ich erstelle einen Manager, der die Anforderungen der Aktionsmethoden für einen MVC-Controller erfüllt. Wenn es eine Methode gäbe, beispielsweise zum Erstellen der Engine-Objekte, die zum Erstellen von Ansichtsmodellen verwendet werden, wäre dies ein Factory-Methodenmuster. Wenn es dagegen zwei Methoden hätte: eine zum Erstellen von Ansichtsmodell-Engines und eine zum Erstellen von Aktionsmodell-Engines (oder wie auch immer Sie das Modell nennen möchten, das die Aktionsmethode Verbraucher enthält), wäre es eine abstrakte Factory.

public ActionResult DoSomething(SpecificActionModel model)
{
    var actionModelEngine = manager.GetActionModelEngine<SpecificActionModel>();
    actionModelEngine.Execute(SpecificActionModelEnum.Value);

    var viewModelEngine = manager.GetViewModelEngine<SpecificViewModel>();
    return View(viewModelEngine.GetViewModel(SpecificViewModelEnum.Value);
}

Obwohl es viele Jahre her ist, dass Leute von StackOverflow in anderen Posts ähnlich zu diesem Thema befragt haben (das älteste geht bis 2009), konnte ich immer noch nicht die gewünschte Antwort finden.

• Unterschiede zwischen abstraktem Fabrikmuster und Fabrikmethode
• Was ist der grundlegende Unterschied zwischen dem Factory- und dem Abstract Factory-Muster?

Also habe ich ein paar Stunden über das Internet recherchiert, die Beispiele überprüft und bin zu dem Schluss gekommen, dass die Hauptunterschiede zwischen Abstract Factory und Factory Method bestehen

• Die Absicht: Kohärenz oder "Look-and-Feel" : Abstract Factory beabsichtigt, eine Familie von Objekten mit demselben Stil zu gruppieren (z. B. dieselben Widgets für die Benutzeroberfläche, dieselben Autoteile, Objekte aus demselben Betriebssystem). etc.) Viele Beispiele aus Abstract Factory erwähnen den Schlüsselbegriff "das gleiche Look-and-Feel".
• Objekte, die ein größeres Gruppenobjekt bilden : Abstract Factory erstellt eine Familie von Objekten, die ein größeres Gruppenobjekt bilden, nicht ein einzelnes Objekt.
• Später einen neuen Stil hinzufügen : Wenn wir weiterhin die Factory-Methode verwenden und versuchen, der vorhandenen Infrastruktur einen neuen Stilsatz hinzuzufügen, wäre dies schmerzhaft. Mit Abstract Factory müssen wir lediglich eine neue konkrete Fabrik erstellen, die die abstrakte Factory-Klasse implementiert.

Die Gegenbeispiele wären

• Ein Autoteil für Sportwagen, das in einer Limousine verwendet wird. Diese Inkonsistenz kann zu Unfällen führen.
• Eine Windows-ähnliche Schaltfläche in verschiedenen Widgets der Betriebssystem-GUI. Es wird nichts kaputt machen, aber die Benutzererfahrung für einige Leute wie mich beeinträchtigen.
• Später stellen wir fest, dass unsere Software beim nächsten Betriebssystem-Upgrade ausgeführt werden muss, für das andere kompatible Systemobjekte erforderlich sind, während die Software abwärtskompatibel bleibt.

Wenn eine endgültige Objektgruppe ohne Ausnahme eines Objekts denselben Stil haben sollte und Sie dieses Detail "denselben Stil beibehalten" ausblenden möchten, sollten wir Abstract Factory verwenden.

Soweit ich die Bedeutung von abstrakten Factory- und Factory-Methodendefinitionen verstehe, wird die erste im statischen Kontext implementiert und liefert Objekte basierend auf Eingabeparametern.

Zweitens wird ein bereits erstelltes Objekt (die Familie) verwendet, das die Factory-Methodenschnittstelle implementiert. Die Factory-Methode erstellt dann eine bestimmte Instanz, die sich auf das ursprüngliche Objekt bezieht, unabhängig davon, um welches es sich handelt.

Dies führt normalerweise dazu, dass beide Muster zusammen verwendet werden, wobei Sie im ersten Schritt ein allgemeines Objekt erstellen, das die Familie verwandter Objekte beschreibt. Es wird von der statischen Methode getInstance ("mein Familienname") aufgerufen. Die Implementierung einer solchen getInstance-Methode entscheidet, welches Familienobjekt erstellt wird.

Dann rufe ich die Methode createProduct () für ein neu erstelltes Familienobjekt auf und abhängig vom Familienobjekt wird das neue Produkt zurückgegeben.

Es scheint, dass diese Muster zu jedem zusammenarbeiten.

Mit anderen Worten, Abstract Factory konzentriert sich auf "WAS" und die Factory-Methode "WIE" wird erstellt.

Alles, woran Sie denken müssen, ist, dass eine abstrakte Fabrik eine Fabrik ist, die mehrere Fabriken zurückgeben kann . Wenn Sie also eine AnimalSpeciesFactory hatten, kann diese Fabriken wie folgt zurückgeben:

Mamalfactory, BirdFactory, Fishfactory, ReptileFactory. Nachdem Sie eine einzelne Factory aus der AnimalSpeciesFactory haben, verwenden sie das Factory-Muster, um bestimmte Objekte zu erstellen. Stellen Sie sich zum Beispiel vor, Sie hätten eine ReptileFactory von dieser AnimalFactory und könnten dann anbieten, Reptilienobjekte wie Schlangen, Schildkröten, Eidechsenobjekte zu erstellen.

/*
//Factory methods:

//1. Factory Method - Abstract Creator Class



#include <iostream>
#include <string.h>
using namespace std;

const std::string nineNintyCC = std::string("990CC");
const std::string thousandTwoHundredCC = std::string("1200CC");
const std::string ThousandFiveHundredCC = std::string("1500CC");
const std::string fiveThousandCC = std::string("5000CC");

// Product
class Engine
{
    public:
    virtual void packEngine() = 0;  
};

// Concrete products
// concrete product class one
class C990CCEngine: public Engine
{

    public:
    void packEngine()
    {
       cout << "Pack 990CC engine" << endl;   
    }
};

// concrete class Two
class C1200CCEngine: public Engine
{   public:
    void packEngine()
    {
        cout << "pack 1200CC engine" << endl;
    }

};

// Concrete class Three
class C1500CCEngine: public Engine
{
    public:
    void packEngine()
    {
        cout << "Pack 1500CC engine" << endl;
    }

};


// Car Factory:
class CarFactory{
    public:

    virtual Engine* createEngine(const std::string& type) = 0;
};
class Factory: public CarFactory
{
    public:
     Engine *createEngine(const std::string& type)
     {

          if(0 == nineNintyCC.compare(type))
          {    
             return new C990CCEngine;
          }
          else if(0 == thousandTwoHundredCC.compare(type))
          {
             return new C1200CCEngine;
          }
          else if(0 == ThousandFiveHundredCC.compare(type))
          {
             return new C1500CCEngine;
          } 
          else
           {
                 cout << "Invalid factory input" << endl;
             return NULL;
           }
           return NULL;
     }
};

int main()
{

    CarFactory* ptr = new Factory;
    Engine*pEngine =  ptr->createEngine(nineNintyCC);
    if(pEngine)
    {
        pEngine->packEngine();
        delete pEngine;
    }
    else
    {
        cout << "No engine exists of your type in our factory" << endl;
    }
    pEngine =  ptr->createEngine(ThousandFiveHundredCC);
    if(pEngine)
    {
        pEngine->packEngine();
        delete pEngine;
    }
    else
    {
        cout << "No engine exists of your type in our factory" << endl;
    }
    pEngine =  ptr->createEngine(thousandTwoHundredCC);
    if(pEngine)
    {
        pEngine->packEngine();
        delete pEngine;
    }
    else
    {
        cout << "No engine exists of your type in our factory" << endl;
    }
    pEngine = ptr-> createEngine(fiveThousandCC);
    if(pEngine)
    {
        pEngine->packEngine();
        delete pEngine;
    }
    else
    {
        cout << "No engine exists of your type in our factory" << endl;
    }
    return 0;
}

*/
/*
//
// interface product
#include <iostream>
#include <string>
using namespace std;

class Engine
{
 public:
 virtual void EngineType() = 0;

};

// concrte product
class AltoEngine: public Engine
{
  public:
  void EngineType()
  {
      cout << "Alto Engine" << endl;
  }
};

//Concrte product
class SwiftEngine : public Engine
{
    public:
    void EngineType()
    {
        cout << "Swift Engine" << endl;    
    }
};

class Body
{
   public:
    virtual void bodyType() = 0;

};

class AltoBody: public Body
{
  public:  
    virtual void bodyType()
    {
        cout << "Alto Car Body" << endl;
    }
};

class SwiftBody : public Body
{
    public:
    void bodyType()
    {
        cout << "SwiftCar Body" << endl;
    }

};


class CarFactory
{
   public:
   virtual Engine* createEngineProduct() = 0;
   virtual Body*   createBodyPoduct() = 0;
};
class AltoCarFactory: public CarFactory
{
    public:
    Engine * createEngineProduct()
    {
        return new AltoEngine;
    }
    Body* createBodyPoduct()
    {
        return new AltoBody;
    }

};

class SwiftCarFactory: public CarFactory
{
    public:
    Engine * createEngineProduct()
    {
        return new SwiftEngine;
    }
    Body* createBodyPoduct()
    {
        return new SwiftBody;
    }

};

int main()
{

    CarFactory* pAltoFactory = new AltoCarFactory;
    Engine* pAltoEngine = pAltoFactory->createEngineProduct();
    pAltoEngine->EngineType();
    Body* pAltoBody = pAltoFactory->createBodyPoduct();
    pAltoBody->bodyType();



    CarFactory* pSwiftFactory = NULL;
    pSwiftFactory = new SwiftCarFactory;
    Engine* pSwiftEngine = pSwiftFactory->createEngineProduct();
    pSwiftEngine->EngineType();
    Body* pSwfitBody = pSwiftFactory->createBodyPoduct();
    pSwfitBody->bodyType();
    delete pAltoBody;
    delete pAltoFactory;
    delete pSwfitBody;
    delete pSwiftFactory;
    return 0;
}
*/

/*

// One more Factory example;

#include <iostream>
#include <string>
using namespace std;

const std::string maruthi = std::string("Maruthi");
const std::string fiat = std::string("Fiat");
const std::string renault = std::string("Renault");
// Interface
class CarEngine
{
 public:
    virtual void engineType() = 0;
};

// Concrete class
class FiatEngine: public CarEngine
{
  public:
  void engineType()
  {
      cout << "Fait Engine Engine" << endl;
  }

};
// ConcreteClass
class RenaultEngine : public CarEngine
{
    public:
    void engineType()
    {
        cout << "Renault Engine" << endl;
    }

};
// Concrete class
class MaruthiEngine : public CarEngine
{
    public:
    void engineType()
    {
        cout << "Maruthi Engine" << endl;
    }
};


// Factory
class CarFactory
{
    public:
    virtual CarEngine* createFactory(const std::string&) = 0;
};

// EngineFactory
class CarEngineFactory : public CarFactory
{
     public:
     CarEngine* createFactory(const std::string&  type)
     {
          if(0 == maruthi.compare(type))
          {
              return new MaruthiEngine;

          }
          else if(0 == fiat.compare(type))
          {
              return  new FiatEngine;
          }
          else if(0 == renault.compare(type))
          {
              return new RenaultEngine;
          }
          else
          {
              cout << "Invalid Engine type" << endl;
              return NULL;
          }
     }

  };

int main()
{
    CarFactory* pCarFactory = new CarEngineFactory;
    CarEngine* pMaruthiCarEngine = pCarFactory->createFactory(maruthi);
    pMaruthiCarEngine->engineType();

    CarEngine* pFiatCarEngine = pCarFactory->createFactory(fiat);
    pFiatCarEngine->engineType();


    CarEngine* pRenaultCarEngine = pCarFactory->createFactory(renault);
    pRenaultCarEngine->engineType();

    return 0;
}


*/


/*

// One more Factory example;

#include <iostream>
#include <string>
using namespace std;

const std::string maruthi = std::string("Maruthi");
const std::string fiat = std::string("Fiat");
const std::string renault = std::string("Renault");


// Interface
class CarEngine
{
 public:
    virtual void engineType() = 0;
};

// Concrete class
class FiatEngine: public CarEngine
{
  public:
  void engineType()
  {
      cout << "Fait Car Engine" << endl;
  }

};

// ConcreteClass
class RenaultEngine : public CarEngine
{
    public:
    void engineType()
    {
        cout << "Renault Car Engine" << endl;
    }

};

// Concrete class
class MaruthiEngine : public CarEngine
{
    public:
    void engineType()
    {
        cout << "Maruthi Car Engine" << endl;
    }
};

// Interface
class CarBody
{
 public:
    virtual void bodyType() = 0;
};

// Concrete class
class FiatBody: public CarBody
{
  public:
  void bodyType()
  {
      cout << "Fait car Body" << endl;
  }

};

// ConcreteClass
class RenaultBody : public CarBody
{
    public:
    void bodyType()
    {
        cout << "Renault Body" << endl;
    }

};

// Concrete class
class MaruthiBody : public CarBody
{
    public:
    void bodyType()
    {
        cout << "Maruthi body" << endl;
    }
};


// Factory
class CarFactory
{
    public:
    virtual CarEngine* createCarEngineProduct() = 0;
    virtual CarBody* createCarBodyProduct() = 0;
};

// FiatFactory
class FaitCarFactory : public CarFactory
{
     public:
     CarEngine* createCarEngineProduct()
     {
        return new FiatEngine; 
     }
     CarBody* createCarBodyProduct()
     {
         return new FiatBody;
     }
};

// Maruthi Factory
class MaruthiCarFactory : public CarFactory
{
     public:
     CarEngine* createCarEngineProduct()
     {
         return new MaruthiEngine;
     }
     CarBody* createCarBodyProduct()
     {
         return new MaruthiBody;
     }

};

// Renault Factory
class RenaultCarFactory : public CarFactory
{
     public:
    CarEngine* createCarEngineProduct()
    {
        return new RenaultEngine;
    }

    CarBody* createCarBodyProduct()
    {
        return new RenaultBody;
    }

};


int main()
{

   // Fiat Factory
   CarFactory* pFiatCarFactory = new FaitCarFactory;
   CarEngine* pFiatEngine = pFiatCarFactory->createCarEngineProduct();
   CarBody*  pFiatBody = pFiatCarFactory->createCarBodyProduct();
   pFiatEngine->engineType();
   pFiatBody->bodyType();

   // Renault Car Factory
    return 0;
}

*/

Das Factory-Methodenmuster ist ein kreatives Entwurfsmuster, das sich mit dem Erstellen von Objekten befasst, ohne die genaue Klasse des zu erstellenden Objekts anzuzeigen. Dieses Entwurfsmuster ermöglicht es einer Klasse grundsätzlich, die Instanziierung auf Unterklassen zu verschieben.

Das Abstract Factory-Muster dient zur Kapselung einer Gruppe einzelner Fabriken, ohne die konkreten Klassen freizulegen. In diesem Modell wird eine generische Schnittstelle einer abstrakten Factory-Klasse verwendet, um das erforderliche konkrete Objekt zu erstellen, das die Details der Implementierung von Objekten von ihrer Verwendung und Zusammensetzung trennt. Dieses Entwurfsmuster wird häufig in GUI-Anwendungen verwendet, in denen ähnliche GUI-Komponenten erstellt werden müssen.

Bei der Suche auf Google bin ich auf den folgenden Blog gestoßen, in dem beide Designmuster brillant erklärt wurden. Schauen Sie sich diese an

http://simpletechtalks.com/factory-design-pattern/

http://simpletechtalks.com/abstract-factory-design-pattern/