Fabbriche astratte Nesting e DI - È accettabile?

Question

Fabbriche astratte Nesting e DI - È accettabile?

#1 da (1 voti)

0

Sto ancora cercando di fare esperienza con DI. Consentitemi di illustrare la mia situazione e potete darmi dei consigli su se sto usando correttamente DI e Abstract Factory.

Ho bisogno di creare IModels in fase di runtime. Quindi userò la DI per iniettare una IModelFactory nei miei oggetti. Ma l'implementazione concreta dei miei IModel dipende da IDataManagers. Questo va bene, posso iniettare IDataManagerFactory nella mia implementazione di IModelFactory. Inoltre, poiché le implementazioni di IDataManager dipendono da IRepository. Posso iniettare IRepositoryFactory nell'implementazione di IDataManager.

Questo tipo di fabbrica astratta concatena il design accettabile? O è un avvertimento che sto percorrendo la strada sbagliata? Tutti gli esempi che vedo online sono fondamentalmente Fabbriche che creano oggetti con dipendenze dei parametri o del tutto assenti.

// Products
class Model : IModel
{
    IDataManger dm;

    ctor(IDataMangerFactory dmFactory)
    {
        dm = dmFactory.Create();
    }
}

class DataManager : IDataManager
{
    IRepository repo;

    ctor(IRepositoryFactory repoFactory)
    {
        repo = repoFactory.Create();
    }
}

class Repo : IRepository
{
    ctor() {}
}

// Factories
class RepoFactory : IRepositoryFactory
{
    public IRepository Create()
    {
        return new Repo();
    }
}

class DmFactory : IDataManagerFactory
{
    IRepositoryFactory repoFactory;

    ctor(IRepositoryFactory factory)
    {
       repoFactory = factory;
    }

    public IDataManager Create()
    {
        return new DataManager(repoFactory);
    }
}

class ModelFactory : IModelFactory
{
    IDataManagerFactory dmFactory;

    ctor(IDataManagerFactory factory)
    {
       dmFactory = factory;
    }

    public IModel Create()
    {
        return new Model(dmFactory);
    }
}

// register the classes into the DI
// Application root instantiates Consumer. DI resolves.

// Consumer
class Consumer
{
    public BindableCollectionOfModels {get;set;}

    IModelFactory modelFactory;
    ctor(IModelFactory factory)
    {
         modelFactory = factory;
    }

    public void UserClicksCreateNewModelInUI()
    {
        var model = modelFactory.Create();
        BindableCollectionOfModels.Add(model);
    }
}

Il mio istinto mi dice che questo può andare in entrambi i modi. Sto scrivendo un sacco di codice extra, aggiungendo complessità, ecc., E qualcosa non mi sembra giusto. D'altra parte, sto ottenendo la possibilità di scambiare le implementazioni lungo tutta la catena. Questo è positivo nel mio progetto perché siamo in una cornice temporale per ottenere prototipi di fronte al cliente, ma una volta che il cliente vede come funziona, abbiamo il tempo di implementare l'implementazione e perfezionarla. Quindi, usando questo metodo, possiamo semplicemente scambiare implementazioni disordinate e inefficienti con implementazioni accurate e raffinate mentre andiamo avanti con il progetto.

La mia domanda è: è un buon uso di Fabbriche astratte e DI o sto sbagliando? Se è così, perché? In caso contrario, spiega.

design dependency-injection abstract-factory

posta Price Jones 20.04.2016 - 15:30

fonte

1 risposta

Leggi altre domande sui tag design dependency-injection abstract-factory

Che tipo di struttura dati dovrebbe essere utilizzata per memorizzare i componenti in un programma di schemi elettrici? Come progettare MVC in JavaFX rispetto alle prestazioni dell'attività non-GUI

score 1 · Accepted Answer

Sono più abituato a vedere l'iniezione delle dipendenze che funziona in termini di oggetti istanziati, piuttosto che nelle fabbriche (a meno che i componenti che si iniettano in abbiano bisogno di creare questi oggetti in modo dinamico post-cablaggio)

es. Vorrei usare le fabbriche per istanziare i componenti in primo piano, e quindi legarli insieme per esempio (in pseudo-Scala, ma l'intento dovrebbe essere chiaro)

val repoFactory = new RepoFactory()
val dmFactory = new DataManagerFactory()

val repo = repoFactory.newRepo()
val dm = dmFactory.newManager(repo)
val model = new Model(dm)

Inierei invece factory se i componenti cablati devono creare al volo componenti successivi, ad es.

val model = new Model(new EntityFactory())

// post-wiring...
if (condition) {
   val entity = model.newEntity()
   entity...
}