it-swarm.com.de

Entwurfsmuster: Abstrakte Fabrik gegen Fabrikmethode

Hinweis: Fragen stehen am Ende des Beitrags.

Ich habe die anderen stackoverflow-Threads bezüglich Abstract Factory vs. Factory Method gelesen. Ich verstehe die Absicht jedes Musters. Die Definition ist mir jedoch nicht klar.

Factory-Methode definiert eine Schnittstelle um ein Objekt zu erstellen, lässt aber Unterklassen entscheiden, welche davon instanziieren Eine Factory-Methode lässt Klassen verschieben die Instantiierung auf Unterklassen.

Im Gegensatz dazu ist eine abstrakte Fabrik bietet eine Schnittstelle zum Erstellen von verwandte oder abhängige Familien Objekte ohne Angabe ihrer konkrete Klassen.

- John Feminella

Die Abstract Factory sieht der Factory-Methode sehr ähnlich. Ich habe ein paar 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 - Entwurfsmuster.

Fabrikmethode:

Factory Method

Abstract Factory (nur 1 Mitglied):

Abstract Factory (only 1 member)

Abstract Factory (mehr Mitglieder):

alt text

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 Factory Method aus einem Interface erstellt werden oder muss er aus einer Klasse stammen? (Klassen verschieben Instantiierungen 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, dass der Ersteller für erstere eine Schnittstelle und der Ersteller für letztere eine ist Klasse?
139
user295190

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

Statische Fabrik

Ist eine Klasse mit einer statischen Methode, um verschiedene Produkttypen zu erzeugen.

Static Factory

Einfache Fabrik

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

Simple Factoryt

Fabrikmethode

Enthält eine Methode, um einen Produkttyp zu erzeugen, der zu seinem Typ gehört. (Dies ist besser als eine einfache Fabrik, da der Typ auf eine Unterklasse verschoben wird.)

Factory Method

Abstrakte Fabrik

Erzeugt eine Familie von verwandten Typen. Es unterscheidet sich deutlich von einer Factory-Methode, da es mehr als eine Methode der von ihr produzierten Typen gibt. (Dies ist kompliziert, siehe das nächste Diagramm für ein besseres Beispiel aus der Praxis).

Abstract Factory

Beispiel aus dem .NET Framework

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

Abstract Factory From .NET Framework

130
user295190

Die beiden Muster sind sicherlich miteinander verbunden!

Der Unterschied zwischen Mustern ist im Allgemeinen beabsichtigt.

Die intent von Factory-Methode lautet "Definieren einer Schnittstelle zum Erstellen eines Objekts, aber lassen Sie die Unterklassen entscheiden, welche Klasse instanziiert werden soll. Mit der Factory-Methode kann eine Klasse die Instantiierung auf Unterklassen verschieben"

Das intent von Abstract Factory ist "Bietet eine Schnittstelle zum Erstellen von Familien verwandter oder abhängiger Objekte, ohne deren konkrete Klassen anzugeben."

Ausgehend von diesen Absichtserklärungen (zitiert von GoF) würde ich sagen, dass Factory Method in gewissem Sinne eine "entartete" Abstract Factory mit einer Familie von einer ist.

Sie neigen im Allgemeinen dazu, sich in der Implementierung zu unterscheiden, da Factory-Methode um einiges einfacher ist als 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 ist Aufgabe der ConcreteProduct-Unterklassen, sie tatsächlich zu erstellen. Die gebräuchlichste Methode hierfür ist die Definition einer Factory-Methode für jedes Produkt.

Dieses c2 Wiki hat auch einige interessante Diskussionen zu diesem Thema.

76
Don Roby

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

  1. Wenn die Abstract Factory nur einen Schöpfer und ein Produkt hat, ist es dann noch das Abstract FactoryMuster? (eine Schnittstelle für Familien erstellen)

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

  1. Kann der Factory Method Concrete Creator aus einem Interface erstellt werden oder muss er aus einer Klasse stammen? (Klassen verschieben Instantiierungen zu Unterklassen)

Zunächst müssen wir beachten, dass weder Java noch C # vorhanden waren, als die GoF ihr Buch schrieb. Die GoF-Verwendung des Begriffs interface hat keinen Bezug zu den durch bestimmte Sprachen eingeführten Schnittstellentypen. Daher kann der konkrete Ersteller von einer beliebigen API erstellt werden. Der wichtige Punkt in diesem Muster ist, dass die API eine eigene Factory-Methode verwendet, sodass eine Schnittstelle mit nur einer Methode nicht mehr eine Factory-Methode sein kann als eine abstrakte Factory.

  1. Wenn die Abstract Factory nur einen Schöpfer und ein Produkt haben kann, besteht der einzige Unterschied zwischen der Abstract Factory und der Factory-Methode dass der Ersteller für erstere eine Schnittstelle und der Ersteller für 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 die Anzahl der erstellten Produkte ist, sollten Sie überlegen, wie ein Client jedes dieser Muster verwendet. Eine abstrakte Fabrik wird normalerweise in ihren Client eingefügt und über die Zusammensetzung/Delegierung aufgerufen. Eine Factory-Methode muss vererbt werden. Es geht also alles um die alte Debatte Komposition vs. Vererbung.

Diese Antworten haben jedoch eine vierte Frage aufgeworfen!

  1. Da eine Schnittstelle mit nur einer Methode nicht eine Factory-Methode sein kann, kann es auch keine Abstract Factory , sein, was nennen wir eine kreative Schnittstelle mit nur einer Methode?

Wenn die Methode statisch ist, wird sie allgemein als Static Factory bezeichnet. Wenn die Methode nicht statisch ist, wird sie allgemein als Simple Factory bezeichnet. Keines dieser Muster ist ein GoF-Muster, aber in der Praxis werden sie viel häufiger verwendet!

13
jaco0646

Meiner Meinung nach liegt der leichte Unterschied zwischen den beiden Mustern in der Anwendbarkeit und, wie bereits gesagt, in der Intent

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

Abstrakte Fabrik

Bereitstellung einer Schnittstelle zum Erstellen von Familien verwandter oder abhängiger Objekte ohne Angabe ihrer konkreten Klassen.

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 Instantiierung auf Unterklassen verschieben.

Beide Muster ermöglichen es, die Benutzerobjekte von der Erstellung erforderlicher Instanzen zu entkoppeln (Laufzeitentkopplung), und dies ist der gemeinsame Aspekt. Beide Muster erlauben es, eine Hierarchie von Fabriken entsprechend den jeweiligen Bedürfnissen zu erstellen. Dies ist ein weiterer allgemeiner Aspekt. 

Abstract Factory ermöglicht es, mehrere verschiedene Arten von Instanzen in einer Unterklasse zu erstellen und das Schöpfungsverhalten in seinen 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 zusammenfassen. Nehmen wir an, Product definiert die Oberklasse der erstellenden Objekte und ProductA und ProductB sind zwei verschiedene Unterklassen. Daher gibt es für die Abstract Factory-Methode zwei Methoden, createProductA () und createProductB (), die in ihren jeweiligen Unterklassen (hinsichtlich der Erstellungsschritte) spezifiziert werden: Die Factory-Unterklassen spezifizieren die creation-Schritte für die zwei definierten Klassen von Objekten, die erstellt werden. 

Gemäß dem obigen Beispiel wird die Factory-Methode unterschiedlich implementiert, wobei die Erstellung von ProductA und ProductB in so vielen Fabriken (eine Methode pro Factory) abstrahiert wird, und die weitere Spezialisierung der Erstellungsschritte an die Hierarchie delegiert wird wie es gebaut ist.

4
Paolo Maresca

Wenn ich ein abstrahiertes erstellt habe (referenziert über eine Schnittstelle oder eine abstrakte Basisklasse) Factory-Klasse, 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 es eine Abstract Factory .

Angenommen, ich erstelle einen Manager, der die Anforderungen von Aktionsmethoden für einen MVC-Controller abdeckt. Wenn es eine Methode gäbe, z. B. zum Erstellen der Engine-Objekte, die zum Erstellen von Ansichtsmodellen verwendet werden, wäre dies eine Factory-Methode Wenn auf der anderen Seite zwei Methoden vorhanden wären: eine zum Erstellen von Ansichtsmodellmodulen und eine andere zum Erstellen von Aktionsmodellmodulen (oder wie auch immer Sie das Modell aufrufen möchten, das die Aktionsmethode Consumer enthält), dann wäre es das eine abstrakte fabrik.

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 die Leute von StackOverflow auf ähnliche Weise in anderen Posts zu diesem Thema befragt haben (älteste geht auf 2009), konnte ich immer noch nicht die gewünschte Antwort finden.


Also recherchierte ich ein paar Stunden im Internet, untersuchte die Beispiele und kam zu diesem Schluss, 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 UI-Widgets mit Look-and-Feel-UI, gleiche Autotypen, Objekte von) ein und dasselbe Betriebssystem usw.) In vielen Beispielen von Abstract Factory wird der Schlüsselwortsatz "dasselbe Look-and-Feel" erwähnt.
  • 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 die Factory-Methode weiterhin verwenden und versuchen, der vorhandenen Infrastruktur einen neuen Satz von Stilen hinzuzufügen, wäre dies schmerzhaft. Mit Abstract Factory müssen wir lediglich eine neue Betonfabrik erstellen, die die abstrakte Fabrikklasse implementiert.

Die Gegenbeispiele wären 

  • Ein Autoteil für einen Sportwagen, der in einer Limousine verwendet wird. Diese Inkonsistenz kann zu Unfällen führen.
  • Eine Schaltfläche im Windows-Stil in verschiedenen GUI-Widgets für Betriebssysteme. Es wird nichts Brechen, aber die Benutzererfahrung wird für manche Leute wie mich verletzt.
  • Später stellen wir fest, dass unsere Software beim nächsten Betriebssystem-Upgrade ausgeführt werden muss, bei dem andere kompatible Systemobjekte benötigt werden, während die Software abwärtskompatibel bleibt.

Wenn eine abschließende Objektgruppe denselben Stil ohne Ausnahme eines Objekts haben soll und Sie dieses Detail "unter Beibehaltung des gleichen Stils" ausblenden möchten, sollten Sie Abstract Factory verwenden.

1
Andrew Chong
/*
//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;
}

*/
0
user1573259

Soweit ich die Bedeutung der abstrakten Factory- und Factory-Methodendefinitionen verstehe, wird die erste im statischen Kontext implementiert und stellt auf Eingabeparametern basierende Objekte bereit.

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

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

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

Es scheint, dass diese Muster mit jedem zusammenarbeiten.

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

0
Jan Stanicek

Factory Method Pattern ist ein kreatives Entwurfsmuster, das sich mit dem Erstellen von Objekten befasst, ohne die genaue Klasse des Objekts anzuzeigen, das erstellt wird. Dieses Entwurfsmuster ermöglicht es grundsätzlich einer Klasse, die Instantiierung auf Unterklassen zu verschieben.

Das Muster der abstrakten Fabrik dient zur Verkapselung für eine 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 deren Verwendung und Zusammensetzung trennt. Dieses Entwurfsmuster wird häufig in GUI-Anwendungen verwendet, bei denen ähnliche Arten von GUI-Komponenten erstellt werden müssen.

während der suche bei google kam ich nach dem blog, der beide design-muster brillant erklärte. schau dir diese an

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

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

0
Neo

Sie müssen sich nur daran erinnern, dass eine abstrakte Fabrik eine Fabrik ist, die mehrere Fabriken zurückgeben kann . Wenn Sie also eine AnimalSpeciesFactory hatten, kann sie folgende Fabriken zurückgeben:

Mamalfactory, BirdFactory, Fishfactory, ReptileFactory. Da Sie jetzt eine einzige 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 erhalten, dann könnten Sie anbieten, Reptilobjekte wie: Schlangen, Schildkröten, Echsenobjekte zu erstellen. 

0
j2emanue