Classe astratta pseudo-fabbrica

0

Quindi ho un requisito per qualcosa di simile:

  • Il client non dovrebbe sapere come sono le classi effettive implementato o costruito.

  • Le classi implementano un'interfaccia comune

Quindi ho usato la classe Factory per soddisfare 1 e una classe astratta per implementare il secondo punto.

Quindi ho trovato qualcosa di simile (una semplificazione del mio design di classe):

#include <iostream>
#include <cstddef>

enum variety{
    oolong,
    green,
};

class T
{
    public:
        virtual void drink() = 0;
        virtual ~T() {};
};

class T1: public T
{
    T1() = delete;
    public:
        T1(int a):
          sugar(a)
          {
              std::cout<<"T1 ctor\n";
          }
        void drink()
        {
            std::cout<<"Sipping oolong with sugar: "<<sugar<<'\n';
        }
        ~T1()
        {
            std::cout<<"T1 dtor\n";
        }
    private:
        int sugar;
};

class T2: public T
{
    T2() = delete;
    public:
        T2(int a):
          sugar(a)
          {
              std::cout<<"T2 ctor\n";
          }
        void drink()
        {
            std::cout<<"Sipping green with sugar: "<<sugar<<'\n';
        }
        ~T2()
        {
            std::cout<<"T2 dtor\n";
        }
    private:
        int sugar;
};

class TFactory
{
    TFactory() = delete;
    public:
        static T* brew(variety v, int sugar){
            if(v == oolong)
                return new T1(sugar);
            else if (v== green)
                return new T2(sugar);
            else
                return nullptr;
        }
};

int main(){
    T* t1 = TFactory::brew(oolong, 5);
    t1->drink();
    delete t1;
}

È questo l'approccio migliore per progettare il mio requisito? O c'è qualche altro modello di design esistente che copre già il mio requisito? Se sì, quali sono le lacune nel mio codice che lo rendono un cattivo design?

    
posta Zoso 14.12.2018 - 12:21
fonte

1 risposta

1

Credo che il nucleo della tua applicazione stia usando la classe astratta T e il TFactory.

In questo caso vuoi separare il nucleo non volatile da frequenti cambiamenti nei sottotipi di T. Ma tu verrai direttamente a dipendere dal TFactory che viola il principio di inversione di dipendenza / principio di apertura chiusa. Il risultato è che ogni volta che aggiungi o modifichi un sottotipo di T il codice che utilizza la Factory viene influenzato dal cambiamento e almeno deve essere ricompilato.

Per risolvere questo problema è possibile posizionare il TFactory dietro un'interfaccia aggiuntiva (Fabbrica astratta) per disaccoppiare i codici.

    
risposta data 15.12.2018 - 14:41
fonte

Leggi altre domande sui tag