Modelli di progettazione: fabbrica astratta vs metodo di fabbrica

Nota: le domande sono alla fine del post.

Ho letto gli altri thread di StackOverflow relativi a Abstract Factory vs Factory Method . Capisco l'intento di ogni modello. Tuttavia, non sono chiaro sulla definizione.

Il metodo Factory definisce un'interfaccia per la creazione di un oggetto, ma consente alle sottoclassi di decidere quale di queste istanziare. Un metodo factory consente alle classi di rinviare l'istanza alle sottoclassi.

Al contrario, una Fabbrica astratta fornisce un'interfaccia per la creazione di famiglie di oggetti correlati o dipendenti senza specificare le loro classi concrete.

- John Feminella

The Abstract Factory è molto simile al metodo Factory . Ho disegnato alcune classi UML per illustrare il mio punto.

Nota:

• I diagrammi provengono da www.yuml.com quindi non sono perfettamente orientati. Ma è un servizio gratuito :).
• Gli schemi potrebbero non essere perfetti. Sto ancora imparando i modelli di progettazione GoF .

Metodo di fabbrica:

Fabbrica astratta (solo 1 membro):

Fabbrica astratta (più membri):

Domande:

1. Se la Fabbrica astratta ha solo un creatore e un prodotto, è ancora il modello Fabbrica astratta? (un'interfaccia per la creazione di famiglie)
2. Il creatore concreto del metodo Factory può essere creato da un'interfaccia o deve appartenere a una classe? (le classi rimandano le istanze alle sottoclassi)
3. Se la Fabbrica astratta può avere solo un creatore e un prodotto, l'unica differenza tra la Fabbrica astratta e il Metodo di fabbrica è che il creatore del primo è un'interfaccia e il creatore del secondo è una classe?

Spero che questo ti aiuti. Descrive i vari tipi di fabbriche. Ho usato Head First Design Patterns come riferimento. Ho usato yuml.me per disegnare .

Fabbrica statica

È una classe con un metodo statico per produrre vari sottotipi di prodotto.

Fabbrica semplice

È una classe che può produrre vari sottotipi di Prodotto. (È meglio della fabbrica statica. Quando vengono aggiunti nuovi tipi, la classe di prodotto di base non deve essere modificata solo la classe di fabbrica semplice)

Metodo di fabbrica

Contiene un metodo per produrre un tipo di prodotto correlato al suo tipo. (È meglio di una semplice fabbrica perché il tipo è rinviato a una sottoclasse.)

Fabbrica astratta

Produce una famiglia di tipi correlati. È notevolmente diverso da un metodo di fabbrica in quanto ha più di un metodo di tipi che produce. (Questo è complicato fare riferimento al diagramma seguente per un migliore esempio di vita reale).

Esempio da .NET Framework

DbFactoriesProvider è una semplice fabbrica in quanto non ha sottotipi. DbFactoryProvider è una fabbrica astratta in quanto può creare vari oggetti di database correlati come oggetti di connessione e comando.

I due modelli sono sicuramente correlati!

La differenza tra i modelli è generalmente intesa.

L' intento del metodo Factory è "Definire un'interfaccia per la creazione di un oggetto, ma lasciare che le sottoclassi decidano quale classe creare un'istanza. Il metodo Factory consente a una classe di rinviare l'istanza alle sottoclassi."

L' intento di Abstract Factory è "Fornire un'interfaccia per la creazione di famiglie di oggetti correlati o dipendenti senza specificare le loro classi concrete".

Basandomi esclusivamente su queste dichiarazioni di intenti (citate da GoF), direi proprio questo Metodo di fabbrica è in un certo senso una Fabbrica astratta "degenerata" con una famiglia di persone.

Generalmente tendono a differire nell'attuazione, come Metodo Factory è molto più semplice di Abstract Factory .

Sono comunque correlati anche nell'attuazione. Come indicato nel libro GoF,

AbstractFactory dichiara solo un'interfaccia per la creazione di prodotti. Spetta alle sottoclassi ConcreteProduct crearle effettivamente. Il modo più comune per farlo è definire un metodo di fabbrica per ciascun prodotto.

Questa wiki c2 ha anche alcune interessanti discussioni su questo argomento.

Sembra che la lista di domande (eccellenti) del PO sia stata ignorata. Le risposte attuali offrono semplicemente definizioni ridisegnate. Quindi cercherò di rispondere in modo conciso alle domande originali.

1. Se la Fabbrica astratta ha solo un creatore e un prodotto, è ancora il modello Fabbrica astratta? (un'interfaccia per la creazione di famiglie)

No . Una Fabbrica astratta deve creare più di un prodotto per creare una "famiglia di prodotti correlati". L'esempio canonico GoF crea ScrollBar()e Window(). Il vantaggio (e lo scopo) è che la Fabbrica astratta può applicare un tema comune ai suoi molteplici prodotti.

2. Il creatore concreto del metodo Factory può essere creato da un'interfaccia o deve appartenere a una classe? (le classi rimandano le istanze alle sottoclassi)

Innanzitutto, dobbiamo notare che né Java né C # esistevano quando il GoF scrisse il loro libro. L'uso da parte del GoF del termine interfaccia non è correlato ai tipi di interfaccia introdotti da particolari linguaggi. Pertanto, il creatore concreto può essere creato da qualsiasi API. Il punto importante nel modello è che l'API utilizza il proprio Metodo di fabbrica, quindi un'interfaccia con un solo metodo non può essere un Metodo di fabbrica più di quanto non possa essere una Fabbrica astratta.

3. Se la Fabbrica astratta può avere solo un creatore e un prodotto, l'unica differenza tra la Fabbrica astratta e il Metodo di fabbrica è che il creatore del primo è un'interfaccia e il creatore del secondo è una classe?

Questa domanda non è più valida, seguendo le risposte sopra; tuttavia, se ti viene da pensare che l'unica differenza tra Abstract Factory e Factory Method sia il numero di prodotti creati, considera come un cliente consuma ciascuno di questi schemi. Una Fabbrica astratta viene generalmente iniettata nel suo client e invocata tramite composizione / delega. Un metodo di fabbrica deve essere ereditato. Quindi tutto ritorna alla vecchia composizione contro il dibattito sull'eredità.

Ma queste risposte hanno sollevato una quarta domanda!

4. Dal momento che un'interfaccia con un solo metodo non può essere un metodo Factory più di quanto non possa essere una Fabbrica astratta , come chiamiamo un'interfaccia creazionale con un solo metodo?

Se il metodo è statico, viene comunemente chiamato fabbrica statica . Se il metodo non è statico, viene comunemente chiamato Simple Factory . Nessuno di questi è un modello GoF, ma in pratica sono molto più comunemente usati!

A mio parere, la leggera differenza tra i due risiede modelli nella applicabilità , e così, come già detto, nel Intent .

Ricapitoliamo le definizioni (entrambe da Wikipedia).

Fabbrica astratta

Fornire un'interfaccia per la creazione di famiglie di oggetti correlati o dipendenti senza specificare le loro classi concrete.

Metodo di fabbrica

Definire un'interfaccia per la creazione di un oggetto , ma lasciare che le classi che implementano l'interfaccia decidano quale classe creare un'istanza . Il metodo Factory consente a una classe di rinviare l'istanza alle sottoclassi.

Entrambi i modelli consentono di separare gli oggetti utente dalla creazione delle istanze necessarie (disaccoppiamento runtime), e questo è l'aspetto comune. Entrambi i modelli consentono di creare una gerarchia di fabbriche in base alle esigenze specifiche, e questo è un altro aspetto comune.

Abstract Factory consente di creare diversi tipi di istanze in una sottoclasse e di particolarizzare il comportamento delle creazioni nelle sue diverse sottoclassi; normalmente, il metodo Factory dichiara la creazione di un solo tipo di oggetto che può essere particolarizzato secondo il meccanismo di sottoclasse. Questa è la differenza

Riassumendo. Diciamo che il Prodotto definisce la superclasse degli oggetti che creano e che ProductA e ProductB sono due diverse sottoclassi. Pertanto, il metodo Fabbrica astratta avrà due metodi, createProductA () e createProductB () che saranno particolarizzati (in termini di passaggi di creazione) nelle sue specifiche sottoclassi: le sottoclassi di fabbrica specificano i passi di creazione per le due classi definite di oggetti in fase di creazione.

Secondo l'esempio precedente, il Metodo di fabbrica verrà implementato in modo diverso, astraggendo la creazione di ProductA e ProductB in altrettante fabbriche (un metodo per Factory) e l'ulteriore specializzazione delle fasi di creazione verrà delegata alla gerarchia man mano che viene costruita .

Se avessi creato una classe Factory astratta (a cui si fa riferimento tramite un'interfaccia o una classe base astratta) che crea oggetti con un solo metodo per creare oggetti, sarebbe un metodo Factory .

Se la Fabbrica astratta avesse più di 1 metodo per creare oggetti, allora sarebbe una Fabbrica astratta .

Diciamo che creo un Manager che gestirà le esigenze dei metodi di azione per un controller MVC. Se avesse un metodo, supponiamo di creare gli oggetti motore che verranno utilizzati per creare i modelli di vista, quindi sarebbe un modello di metodo di fabbrica. D'altra parte, se avesse due metodi: uno per creare i motori del modello di visualizzazione e un altro per creare i motori del modello di azione (o qualunque cosa tu voglia chiamare il modello che il metodo di azione contiene consumatori), sarebbe una fabbrica astratta.

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

Anche se sono passati molti anni da quando le persone di StackOverflow si sono poste domande su questo problema in modo simile in altri post (il più vecchio va al 2009), non riuscivo ancora a trovare la risposta che volevo.

• Differenze tra il modello di fabbrica astratto e il metodo di fabbrica
• Qual è la differenza di base tra i modelli Factory e Abstract Factory?

Così ho fatto alcune ore di ricerche attraverso il web, rivedendo gli esempi e sono giunto a questa conclusione, le principali differenze di Abstract Factory dal metodo Factory sono

• L'intenzione: coerenza o "aspetto grafico" : l'intenzione di Abstract Factory è quella di raggruppare una famiglia di oggetti con lo stesso stile (es. Widget dell'interfaccia utente dello stesso aspetto grafico, parti di automobili dello stesso stile, oggetti di uno stesso sistema operativo, ecc.) Molti esempi tratti da Abstract Factory citano la frase chiave "lo stesso aspetto".
• Oggetti che formano un oggetto di gruppo più grande : Abstract Factory crea una famiglia di oggetti che formano un oggetto di gruppo più grande, non un singolo oggetto.
• In seguito aggiungi un nuovo stile : se continuassimo ad usare il metodo Factory e provassimo ad aggiungere un nuovo set di stili all'infrastruttura esistente, sarebbe doloroso. Con Abstract Factory, tutto ciò che dobbiamo fare è semplicemente creare una nuova fabbrica di cemento che implementa la classe di fabbrica astratta.

Gli esempi contrari sarebbero

• Una parte di auto per auto sportiva utilizzata in una berlina. Questa incoerenza può portare a incidenti.
• Un pulsante in stile Windows in diversi widget della GUI del sistema operativo. Non romperà nulla ma danneggerà l'esperienza dell'utente per alcune persone, come me.
• Successivamente, scopriamo che il nostro software deve essere eseguito nel prossimo aggiornamento del sistema operativo che necessita di diversi set di oggetti di sistema compatibili mantenendo il software compatibile con le versioni precedenti.

Pertanto, quando un gruppo di oggetti finale deve avere lo stesso stile senza un'eccezione di un oggetto e si desidera nascondere questo dettaglio "mantenendo lo stesso stile", è necessario utilizzare Abstract Factory.

Per quanto ne capisco il significato o Definizioni di fabbrica astratta e Metodo di fabbrica la prima è implementata in un contesto statico e fornisce un oggetto basato su parametri di input.

Il secondo utilizza l'oggetto già creato (la famiglia) che implementa l'interfaccia del metodo factory. Il metodo factory quindi crea un'istanza specifica correlata all'oggetto originale, indipendentemente da quale sia.

Quindi questo di solito porta all'uso di entrambi i modelli insieme in cui nel primo passo si crea un oggetto generale che descrive la famiglia di oggetti correlati. Viene chiamato dal metodo statico getInstance ("il mio cognome"). L'implementazione di tale metodo getInstance decide quale oggetto famiglia verrà creato.

Quindi chiamo il metodo createProduct () sull'oggetto familiare appena creato e, a seconda dell'oggetto familiare, verrà restituito il nuovo prodotto.

Sembra che questi schemi cooperino a ciascuno.

In altre parole, Abstract Factory si concentra su "COSA verrà creato" e verrà creato il metodo Factory "COME".

Tutto quello che devi ricordare è che una fabbrica astratta è una fabbrica che può restituire più fabbriche . Quindi se hai avuto un AnimalSpeciesFactory può restituire fabbriche come questa:

Mamalfactory, BirdFactory, Fishfactory, ReptileFactory. Ora che hai una singola fabbrica da AnimalSpeciesFactory, usano il modello di fabbrica per creare oggetti specifici. Ad esempio, immagina di avere una ReptileFactory da questa AnimalFactory, quindi potresti offrirti di creare oggetti di rettili come: serpenti, tartarughe, lucertole.

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

*/

Il modello del metodo di fabbrica è un modello di progettazione creazionale che si occupa della creazione di oggetti senza mostrare la classe esatta di oggetto che viene creata. Questo modello di progettazione consente sostanzialmente a una classe di ignorare l'istanza in sottoclassi.

Il modello Abstract Factory serve l'incapsulamento di un gruppo di singole fabbriche senza esporre le classi concrete. In questo modello, viene utilizzata un'interfaccia generica di una classe factory astratta per creare l'oggetto concreto richiesto che separa i dettagli dell'implementazione degli oggetti dal loro utilizzo e composizione. Questo modello di progettazione è ampiamente utilizzato nelle applicazioni GUI in cui è necessario creare un tipo simile di componenti GUI.

mentre cercavo su google mi sono imbattuto nel blog che spiegava brillantemente entrambi i modelli di design. dai un'occhiata a questi

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

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