Wzorce projektowe: abstrakcyjna fabryka a metoda fabryczna

Uwaga: pytania znajdują się na końcu postu.

Przeczytałem inne wątki stackoverflow dotyczące Abstract Factory vs Factory Method . Rozumiem intencję każdego wzoru. Nie mam jednak jasności co do definicji.

Factory Method definiuje interfejs do tworzenia obiektu, ale pozwala podklasom zdecydować, które z nich mają zostać utworzone. Metoda fabryczna pozwala klasom odroczyć tworzenie instancji do podklas.

Z kolei fabryka abstrakcyjna zapewnia interfejs do tworzenia rodzin powiązanych lub zależnych obiektów bez określania ich konkretnych klas.

- John Feminella

Abstract Factory wygląda bardzo podobnie do metody fabryki . Narysowałem kilka klas UML, aby zilustrować mój punkt widzenia.

Uwaga:

• Diagram pochodzi z www.yuml.com, więc nie są one idealnie zorientowane. Ale to darmowa usługa :).
• Diagramy mogą nie być doskonałe. Wciąż uczę się wzorców projektowych GoF .

Metoda fabryczna:

Abstract Factory (tylko 1 członek):

Abstract Factory (więcej członków):

Pytania:

1. Jeśli Fabryka Abstrakcji ma tylko jednego twórcę i jeden produkt, czy nadal jest to wzorzec Fabryki Abstrakcji ? (interfejs do tworzenia rodzin)
2. Czy kreator betonu Factory Method można utworzyć z interfejsu, czy też musi on pochodzić z klasy? (klasy odraczają instancje do podklas)
3. Jeśli Fabryka Abstrakcji może mieć tylko jednego twórcę i jeden produkt, to czy jedyną różnicą między Fabryką Abstrakcji a Metodą Fabryczną jest to, że twórcą pierwszej jest Interfejs, a twórcą drugiej jest Klasa?

Mam nadzieję że to pomoże. Opisuje różne typy fabryk. Jako odniesienie użyłem Head First Design Patterns . Użyłem yuml.me do tworzenia diagramu.

Fabryka statyczna

To klasa z metodą statyczną do wytwarzania różnych podtypów produktów.

Prosta fabryka

To klasa, która może wytwarzać różne podtypy produktów. (Jest lepszy niż Static Factory. Gdy dodawane są nowe typy, podstawowa klasa produktu nie musi być zmieniana tylko na prostą klasę fabryczną)

Metoda fabryczna

Zawiera jedną metodę wytwarzania jednego rodzaju produktu związanego z jego rodzajem. (Jest lepszy niż Simple Factory, ponieważ typ jest odroczony do podklasy.)

Fabryka abstrakcyjna

Tworzy rodzinę typów, które są ze sobą powiązane. Różni się ona wyraźnie od metody fabrycznej, ponieważ ma więcej niż jedną metodę typów, które wytwarza. (Jest to skomplikowane, patrz następny diagram, aby uzyskać lepszy przykład z życia wzięty).

Przykład z .NET Framework

DbFactoriesProvider jest prostą fabryką, ponieważ nie ma podtypów. DbFactoryProvider to fabryka abstrakcyjna, ponieważ może tworzyć różne powiązane obiekty bazy danych, takie jak obiekty połączeń i poleceń.

Wcześniejsze

Te dwa wzorce są z pewnością powiązane!

Różnica między wzorami jest generalnie intencjonalna.

Intencja od Factory Method jest „Zdefiniować interfejs do tworzenia obiektu, ale niech podklasy zdecydować jakiej klasy instancji. Metoda pozwala na fabryczne instancji klasy odraczać podklasy.”

Zamiar z Abstract Factory jest „Zapewnienie interfejs do tworzenia rodzin powiązanych lub zależnych obiektów bez określania ich konkretnych klas.”

Opierając się wyłącznie na tych stwierdzeniach intencyjnych (cytowanych z GoF), powiedziałbym, że rzeczywiście Metoda Fabryki jest w pewnym sensie „zdegenerowaną” Fabryką Abstrakcyjną z jedną rodziną.

Zwykle różnią się implementacją, ponieważ Metoda Fabryczna jest dużo prostsza niż Fabryka Abstrakcyjna .

Są one jednak powiązane również w realizacji. Jak zauważono w książce GoF,

AbstractFactory deklaruje tylko interfejs do tworzenia produktów. Ich utworzenie zależy od podklas ConcreteProduct. Najczęstszym sposobem na to jest zdefiniowanie metody fabrycznej dla każdego produktu.

Ta wiki c2 również zawiera interesującą dyskusję na ten temat.

Wydaje się, że lista (doskonałych) pytań PO została zignorowana. Aktualne odpowiedzi podają jedynie przeformułowane definicje. Dlatego spróbuję zwięźle odpowiedzieć na pierwotne pytania.

1. Jeśli Fabryka Abstrakcji ma tylko jednego twórcę i jeden produkt, czy nadal jest to wzorzec Fabryki Abstrakcji ? (interfejs do tworzenia rodzin)

Nie . Fabryka abstrakcyjna musi stworzyć więcej niż jeden produkt, aby stworzyć „rodzinę powiązanych produktów”. Przykład kanonicznego GoF tworzy ScrollBar()i Window(). Zaletą (i celem) jest to, że Abstract Factory może wymusić wspólny motyw w wielu swoich produktach.

2. Czy kreator betonu Factory Method można utworzyć z interfejsu, czy też musi on pochodzić z klasy? (klasy odraczają instancje do podklas)

Po pierwsze, musimy zauważyć, że ani Java, ani C # nie istniały, kiedy GoF pisali swoją książkę. Użycie terminu interfejs przez GoF nie jest związane z typami interfejsów wprowadzonymi przez poszczególne języki. Dlatego też kreator betonu można utworzyć z dowolnego interfejsu API. Ważnym punktem we wzorcu jest to, że API używa własnej metody fabrycznej, więc interfejs z tylko jedną metodą nie może być metodą fabryczną, tak samo jak nie może być fabryką abstrakcyjną.

3. Jeśli Fabryka Abstrakcji może mieć tylko jednego twórcę i jeden produkt, to czy jedyną różnicą między Fabryką Abstrakcji a Metodą Fabryczną jest to, że twórcą pierwszej jest Interfejs, a twórcą drugiej jest Klasa?

To pytanie nie jest już aktualne, po odpowiedziach powyżej; jeśli jednak myślisz, że jedyną różnicą między Abstract Factory a Factory Method jest liczba utworzonych produktów, zastanów się, w jaki sposób klient konsumuje każdy z tych wzorców. Fabryka abstrakcyjna jest zwykle wstrzykiwana do swojego klienta i wywoływana poprzez kompozycję / delegację. Należy odziedziczyć metodę fabryczną. Więc wszystko wraca do starej debaty na temat składu i dziedziczenia.

Ale te odpowiedzi wywołały czwarte pytanie!

4. Ponieważ interfejs z tylko jedną metodą nie może być Metodą Fabryczną , tak samo jak nie może być Fabryką Abstrakcji , jak nazywamy interfejs kreacyjny z tylko jedną metodą?

Jeśli metoda jest statyczna, jest powszechnie nazywana statyczną fabryką . Jeśli metoda jest niestatyczna, jest powszechnie nazywana prostą fabryką . Żaden z nich nie jest wzorcem GoF, ale w praktyce są one znacznie częściej używane!

Moim zdaniem niewielka różnica między tymi dwoma wzorami polega na stosowalności , a więc, jak już powiedziano, w Intencji .

Podsumujmy definicje (obie z Wikipedii).

Fabryka abstrakcyjna

Zapewnij interfejs do tworzenia rodzin powiązanych lub zależnych obiektów bez określania ich konkretnych klas.

Metoda fabryczna

Zdefiniuj interfejs do tworzenia obiektu , ale pozwól klasom, które implementują interfejs, zdecydować, która klasa ma zostać utworzona . Metoda Factory pozwala klasie odroczyć tworzenie instancji do podklas.

Oba wzorce pozwalają oddzielić obiekty użytkownika od tworzenia potrzebnych instancji (oddzielenie w czasie wykonywania) i jest to wspólny aspekt. Oba schematy pozwalają na stworzenie hierarchii fabryk według konkretnych potrzeb i jest to kolejny wspólny aspekt.

Abstract Factory pozwala na tworzenie kilku różnych typów instancji w jednej podklasie i uszczegółowienie zachowania kreacji w jej różnych podklasach; normalnie metoda Factory deklaruje utworzenie tylko jednego typu obiektu, który można uszczegółowić zgodnie z mechanizmem podklas. To jest różnica.

Podsumowując. Powiedzmy, że Product definiuje superklasę tworzonych obiektów, a ProductA i ProductB to dwie różne podklasy. Dlatego metoda Abstract Factory będzie miała dwie metody, createProductA () i createProductB (), które zostaną uszczegółowione (pod względem kroków tworzenia) w swoich określonych podklasach: podklasy fabryki wyszczególniają kroki tworzenia dla dwóch zdefiniowanych klas obiektów w trakcie tworzenia.

Zgodnie z powyższym przykładem, Metoda Fabryki zostanie zaimplementowana w różny sposób, abstrahując tworzenie ProduktuA i ProduktuB w tylu fabrykach (jedna metoda na Fabrykę), a dalsza specjalizacja kroków tworzenia zostanie przekazana hierarchii w miarę jej budowania .

Gdybym utworzył abstrakcyjną (do której odwołuje się interfejs lub abstrakcyjna klasa bazowa) klasę Factory, która tworzy obiekty, które mają tylko jedną metodę tworzenia obiektów, to byłaby to metoda Factory .

Gdyby wyabstrahowana fabryka miała więcej niż 1 metodę tworzenia obiektów, byłaby to fabryka abstrakcyjna .

Powiedzmy, że tworzę Menedżera, który będzie obsługiwał potrzeby metod akcji dla kontrolera MVC. Gdyby miał jedną metodę, powiedzmy do tworzenia obiektów silnika, które będą używane do tworzenia modeli widoków, byłby to wzorzec metody fabryki. Z drugiej strony, gdyby miał dwie metody: jedną do tworzenia silników modelu widoku, a drugą do tworzenia silników modeli działań (lub jakkolwiek chcesz nazwać model, że metoda akcji zawiera konsumentów), byłaby to fabryka abstrakcyjna.

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

Chociaż minęło już wiele lat, odkąd ludzie ze StackOverflow podobnie pytali o ten problem w innych postach (najstarszy pochodzi z 2009 r.), Nadal nie mogłem znaleźć odpowiedzi, której szukałem.

• Różnice między abstrakcyjnym wzorcem fabrycznym a metodą fabryczną
• Jaka jest podstawowa różnica między wzorcem fabrycznym a abstrakcyjnym wzorcem fabrycznym?

Zrobiłem więc kilka godzin przeszukiwania sieci, przeglądając przykłady i doszedłem do wniosku, że główne różnice między Abstract Factory a Factory Method to

• Intencja: spójność lub „wygląd i styl” : Intencją Abstract Factory jest zgrupowanie rodziny obiektów o tym samym stylu (np. Widżety interfejsu użytkownika o tym samym wyglądzie i działaniu, części samochodowe w tym samym stylu, obiekty z tego samego systemu operacyjnego, itp.) Wiele przykładów z Abstract Factory wspomina o frazie kluczowej „ten sam wygląd i styl”.
• Obiekty tworzące większą grupę obiektów : Abstract Factory tworzy rodzinę obiektów tworzących większą grupę obiektów, a nie pojedynczy obiekt.
• Później dodaj nowy styl : jeśli nadal będziemy używać metody fabrycznej i spróbujemy dodać nowy zestaw stylu do istniejącej infrastruktury, byłoby to bolesne. W przypadku Abstract Factory wystarczy tylko stworzyć nową fabrykę betonu, która implementuje abstrakcyjną klasę fabryki.

Przykłady liczników byłyby

• Część samochodowa do samochodu sportowego używanego w sedanie. Ta niespójność może prowadzić do wypadków.
• Przycisk w stylu Windows w różnych widżetach GUI systemu operacyjnego. Nie zepsuje niczego, ale zaszkodzi doświadczeniu użytkownika dla niektórych osób, takich jak ja.
• Później dowiadujemy się, że nasze oprogramowanie musi działać w następnej aktualizacji systemu operacyjnego, która wymaga innego zestawu kompatybilnych obiektów systemowych, zachowując jednocześnie kompatybilność wsteczną oprogramowania.

Dlatego też, gdy końcowa grupa obiektów powinna mieć ten sam styl bez wyjątku obiektu, a chcesz ukryć ten szczegół dotyczący zachowania tego samego stylu, powinniśmy użyć Abstract Factory.

O ile rozumiem znaczenie o Definicje abstrakcyjnej fabryki i metody Factory, pierwsza jest zaimplementowana w kontekście statycznym i dostarcza obiekt na podstawie parametrów wejściowych.

Drugi wykorzystuje już utworzony obiekt (rodzinę), który implementuje fabryczny interfejs metody. Metoda fabryki tworzy następnie konkretną instancję związaną z oryginalnym obiektem, bez względu na to, który to jest.

Więc to zwykle prowadzi do użycia obu wzorów razem, gdzie w pierwszym kroku tworzysz jakiś ogólny obiekt, który opisuje rodzinę powiązanych obiektów. Jest wywoływana metodą statyczną getInstance („moje nazwisko”). Implementacja takiej metody getInstance decyduje, który obiekt rodziny zostanie utworzony.

Następnie wywołuję metodę createProduct () na nowo utworzonym obiekcie rodziny i zależnym obiekcie rodziny nowy produkt zostanie zwrócony.

Wydaje się, że te wzorce współpracują ze sobą.

Innymi słowy Fabryka abstrakcyjna skupia się na tym, „CO” zostanie stworzone i metoda Fabryki „JAK” powstanie.

Musisz tylko pamiętać, że abstrakcyjna fabryka to fabryka, która może zwrócić wiele fabryk . Więc jeśli masz AnimalSpeciesFactory, może zwrócić takie fabryki:

Mamalfactory, BirdFactory, Fishfactory, ReptileFactory. Teraz, gdy masz już jedną fabrykę z AnimalSpeciesFactory, używają oni wzorca fabryki do tworzenia określonych obiektów. Na przykład, wyobraź sobie, że masz ReptileFactory z tej AnimalFactory, a następnie możesz zaoferować tworzenie obiektów gadów, takich jak: węże, żółwie, obiekty jaszczurki.

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

*/

Wzorzec metody fabryki to kreacyjny wzorzec projektowy, który zajmuje się tworzeniem obiektów bez pokazywania dokładnej klasy tworzonego obiektu. Ten wzorzec projektowy w zasadzie pozwala klasie odroczyć tworzenie instancji do podklas.

Wzorzec Fabryka abstrakcyjna służy hermetyzacji do grupy pojedynczych fabryk bez ujawniania konkretnych klas. W tym modelu generyczny interfejs abstrakcyjnej klasy fabryki jest używany do tworzenia wymaganego konkretnego obiektu oddzielającego szczegóły implementacji obiektów od ich użycia i składu. Ten wzorzec projektowy jest szeroko stosowany w aplikacjach GUI, w których trzeba utworzyć podobne komponenty GUI.

podczas wyszukiwania w google natknąłem się na blog, który świetnie wyjaśniał oba wzorce projektowe. spójrz na to

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

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