Domanda su fabbriche astratte e iniezione

Question

Questo è simile a una delle mie altre domande, ma abbastanza diverso penso di giustificare una nuova domanda.

Fondamentalmente sto scrivendo un'interfaccia utente e la mia interfaccia utente ha nodi che possono essere selezionati. Quando viene selezionato un nodo, l'interfaccia utente termina con una classe base di nodo astratta "INode". Da questo ottengo una factory facendo node-> getFactory(), e da questo posso creare le finestre di dialogo o le viste appropriate per quel nodo perché il factory corretto viene restituito dal nodo concreto (ad esempio factory-> createAddDialog(), factory- > createView (nodo), ecc.).

La mia domanda è di provare a trovare il modo migliore per quella fabbrica di entrare nel nodo in primo luogo.

Finora ho pensato di 3 modi:

1) Iniettare la corretta fabbrica quando creo il nodo:

AreaNode *node = new AreaNode(new AreaNodeFactory()); 

Così la definizione di AreaNode è:

AreaNode : public INode 
{ 
    AreaNode(INodeAbstractFactory *injectedFactory) 
    { 
     m_injectedFactory = injectedFactory; 
    } 

    INodeAbstractFactory* getFactory() 
    { 
     return m_injectedFactory; 
    } 

    INodeAbstractFactory* m_injectedFactory; 
}; 

2) Iniettare uno stabilimento più generale e consentire al nodo di ottenere la fabbrica da quella fabbrica:

AreaNode : public INode 
{ 
    AreaNode(IFactory *injectedFactory) 
    { 
     m_injectedFactory = injectedFactory; 
    } 

    INodeAbstractFactory* getFactory() 
    { 
     return m_injectedFactory->getAreaNodeFactory(); 
    } 

    IFactory* m_injectedFactory; 
} 

3) Basta creare la fabbrica di cemento (anche se questo elimina la possibilità di utilizzare diverse fabbriche per lo stesso nodo, forse per il test o per le modifiche successive):

AreaNode : public INode 
{ 
    INodeAbstractFactory* getFactory() 
    { 
     return new AreaNodeFactory(); 
    } 
} 

pensieri attuali su queste opzioni:

Opzione 1: Potrebbe essere un po 'casuale: dovrei assicurarmi di dargli sempre la fabbrica corretta per quel tipo, o forse potrei semplicemente usare un'altra fabbrica per iniettare la fabbrica corretta per me.

Opzione 2: costringe il nodo a conoscere l'implementazione della fabbrica astratta abbastanza da essere in grado di chiamare getAreaNodeFactory, che potrebbe non essere una cosa così brutta. Almeno aiuta a garantire che lo stesso factory sia sempre corretto (presupponendo che lo stabilimento più generale sia implementato correttamente).

Opzione 3: Questo si sente un po 'restrittivo in quanto non sarò in grado di scambiare la lezione, e non sono entusiasta del nodo che deve conoscere l'implementazione concreta della fabbrica - anche se in questo caso potrebbe non essere troppo di un problema (ultime parole famose!).

Qualche idea su questo?

Grazie.

MODIFICA: Scusate le dichiarazioni delle variabili nel post di origine, corrette.

EDIT: Un altro problema con l'opzione 2 è che devo attuare "getFactory" in ogni tipo di nodo. Almeno con l'opzione 1, la classe base può solo restituire ogni volta l'inject abstract factory.

Answer 1

Come su

class FactoryBase { /* interface */ } 
template <typename NodeType> class Factory : public FactoryBase { 
    // Default implementation. 
} 
// Add appropriate specializations for all relevant nodetypes, if needed. 
template <typename NodeType> inline Factory<NodeType> getFactory(NodeType*) { 
    return Factory<NodeType>(); 
} 

class AreaNode : public Node { 
    FactoryBase getFactory() { return getFactory(this); } 
}; 

Template argomento deduzione farà in modo che il tipo di fabbrica è derivato da this. Questo dovrebbe impedire errori manuali lì. Ma in generale, non mi preoccuperei di esporre pubblicamente una fabbrica. Basta aggiungere i seguenti bit alla classe di base:

class Node { 
public: 
    std::Auto_ptr<View> createView() { 
    this->getFactory()->createView(this); 
    } // etc. 
private: 
    virtual FactoryBase* getFactory() = 0; 
}; 

Answer 2

Che ne dici?

template<typename Factory> 
class AreaNode : public INode 
{ 
public: 
     virtual ~AreaNode(){} 

     AreaNode() : pFactory_(new Factory()) 
     {   
     } 

     const shared_ptr<IFactory>& GetFactory() 
     { 
      return pFactory_; 
     } 
private:   
     shared_ptr<IFactory> pFactory_; 
}; 

EDIT:

O a seconda del contesto.

template<typename Factory> 
class Node 
{ 
public: 
     virtual ~Node(){} 

     Node() : pFactory_(new Factory()) 
     {   
     } 

     const shared_ptr<IFactory>& GetFactory() 
     { 
      return pFactory_; 
     } 
private:   
     shared_ptr<IFactory> pFactory_; 
}; 

class AreaNode : public Node<AreaNodeFactory> 
{ 
    // Implementation 
}; 

// OR 

typedef Node<AreaNodeFactory> AreaNode; 

Answer 3

dipende dallo scopo del "nodo" oggetti

Se una fabbrica dovrebbe essere iniettato in un nodo e nodo di cemento non devono fare qualsiasi cosa con il tipo concreto della fabbrica, quindi tutto il codice relativo alla fabbrica può essere spostato nella classe del nodo di base, semplificando tutto.

class INode //well, it's not "interface" in clear sense 
{ 
public: 
    void setFactory(Factory* f) { this->f = f; } 
    Factory* getFactory() const { return f; } 
private: 
    Factory* f; 
}; 

Ora, la funzionalità dei nodi calcestruzzo e fabbriche di calcestruzzo è fatto ortogonali tra loro e può essere liberamente combinati in qualsiasi modo.

Se un tipo concreto di nodo è associato a un tipo concreto di fabbrica, potrebbe essere opportuno evitare le fabbriche e creare viste direttamente con il metodo node :: createView. Dipende dal fatto che le fabbriche siano utilizzate in un altro contesto.

Guarda anche questo (modo non molto OOP-ish):

typedef boost::function0<Factory*> Node; 
std::map<UIItem*,Node> nodes; 
nodes[area_item1] = &getAreaFactory; 
nodes[area_item2] = &getAreaFactory; 
nodes[region_item1] = &getRegionFactory; 
... 
void OnSelect(UIItem* i) 
{ 
    ... 
    View* v = nodes[i]()->createView(); 
    ... 
} 

Forse, si adatta tutte le vostre esigenze)