Iniettare o meno le dipendenze in un framework basato su componenti

Question

Iniettare o meno le dipendenze in un framework basato su componenti

#1 da (0 voti)

0

Attualmente sto sviluppando un piccolo framework basato su componenti, la piattaforma Android. Il framework ha alcuni aspetti pratici e alcuni elementi astratti (ha una logica interna, ma lo sviluppatore ha bisogno di aggiungere del codice per renderlo pienamente funzionale). Tutta la comunicazione tra i componenti è soddisfatta utilizzando le interfacce. La mia domanda è:

Sapendo che alcuni componenti hanno dipendenze, il mio framework dovrebbe fornirgli automaticamente?

E.g. : ho un un componente che "necessita" componente B . All'inizio ho pensato a due soluzioni:

Il mio framework dovrebbe creare e iniettare automaticamente il componente B quando lo sviluppatore crea un'istanza del componente A. Se B è un componente astratto, vorrei creare e fornire un'istanza default . / p>
Il framework dovrebbe spiegare nell'API che un componente ha bisogno del componente B e quindi lasciare allo sviluppatore l'istanziazione del componente B e passarlo come dipendenza a A.

Nella seconda soluzione lo sviluppatore potrebbe anche creare un nuovo componente che rispetti il contratto (interfacce) con il componente A e quindi utilizzarlo.

Quale di queste soluzioni porterebbe a una migliore manutenzione, flessibilità ed espansione sia del framework che del codice degli sviluppatori? Accetto altre soluzioni.

dependency-injection architecture frameworks component

posta Rômulo.Edu 13.08.2015 - 21:48

fonte

1 risposta

Leggi altre domande sui tag dependency-injection architecture frameworks component

Organizzazione del codice in X ++ in cui tutte le classi per l'applicazione si trovano in un elenco di classi lunghe Voglio solo chiarire le cose sul comportamento di Session in Asp.Net MVC

score 0 · Accepted Answer

Esegui entrambi

Se stai creando un framework, la flessibilità è la chiave. La maggior parte dei framework fornisce interfacce e implementazioni predefinite insieme a costruttori vuoti cablati ai valori predefiniti, ma consente di sovrascrivere il comportamento passando le proprie implementazioni o passando in un'implementazione alternativa fornita dal framework.

public interface IReader { string Read(); }
public interface IWriter { void Write(String str); }

public class DefaultReader: IReader
{
    public string Read()
    {
        File.ReadAll("c:\myfile.cnf");
    }
}

public class DefaultWriter: IWriter
{
    public void Write(String str)
    {
        File.Write("c:\myfile.cnf", str);
    }
}

public class MyFrameWorkClass
{
    private IReader reader;
    private IWriter writer;

    public MyFrameWorkClass():
        this(new DefaultReader(), new DefaultWriter())
    {
    }

    public MyFrameWorkClass(IReader reader, IWriter writer)
    {
        this.reader = reader;
        this.writer = writer;
    }
}

Il motivo per cui i framework funzionano in questo modo è semplice: non possono fornire alcun DI perché ciò li lega intrinsecamente a un framework DI. L'unica cosa che possono fare (e dovrebbero fare) è fornire classi che possono essere DIE facilmente. Se si sta andando per la massima flessibilità, il codice sopra avrebbe anche proprietà pubbliche che possono essere assegnate. In questo modo, qualsiasi DI-framework può essere collegato e utilizzare il framework con un'iniezione basata su costruttore o basata su proprietà.

Se si desidera fornire una quantità di DI pronta all'uso per i propri oggetti, sarà necessario creare componenti separati che eseguono il binding per il proprio framework. Ad esempio, se stavo usando Castle Windsor per DI, fornirei una classe Installer che può essere inserita.