Differenza tra iniezione di dipendenza (DI) e inversione di controllo (IOC)

Ho visto molti riferimenti a Dependency Injection (DI) e Inversion Of Control (IOC), ma non so davvero se c'è una differenza tra loro o no.

Vorrei iniziare a usarne uno o entrambi, ma sono un po 'confuso su come siano diversi.

definizioni

L'inversione del controllo è un paradigma di progettazione con l'obiettivo di ridurre la consapevolezza delle implementazioni concrete dal codice del framework dell'applicazione e dare un maggiore controllo ai componenti specifici del dominio dell'applicazione. In un tradizionale sistema progettato dall'alto verso il basso, il flusso logico dell'applicazione e la consapevolezza della dipendenza fluiscono dai componenti principali, quelli progettati per primi, a quelli progettati per ultimi. Come tale, l'inversione del controllo è un'inversione quasi letterale del controllo e della consapevolezza della dipendenza in un'applicazione.

L'iniezione di dipendenza è un modello utilizzato per creare istanze di classi su cui fanno affidamento altre classi senza sapere al momento della compilazione quale implementazione verrà utilizzata per fornire quella funzionalità.

Lavorare insieme

L'inversione del controllo può utilizzare l'iniezione di dipendenza perché è necessario un meccanismo per creare i componenti che forniscono la funzionalità specifica. Esistono e vengono utilizzate altre opzioni, ad esempio attivatori, metodi di fabbrica, ecc., Ma i framework non devono fare riferimento a tali classi di utilità quando le classi di framework possono accettare la dipendenza o le dipendenze di cui hanno bisogno.

Esempi

Un esempio di questi concetti al lavoro è il framework dei plug-in in Reflector . I plug-in hanno un grande controllo del sistema anche se l'applicazione non sapeva nulla dei plug-in al momento della compilazione. Viene chiamato un singolo metodo su ciascuno di questi plug-in, Inizializza se la memoria serve, che passa il controllo al plug-in. Il framework non sa cosa faranno, lo lascia semplicemente fare. Il controllo è stato preso dall'applicazione principale e dato al componente che esegue il lavoro specifico; inversione di controllo.

Il framework dell'applicazione consente l'accesso alla sua funzionalità attraverso una varietà di fornitori di servizi. A un plug-in vengono forniti riferimenti ai fornitori di servizi al momento della creazione. Queste dipendenze consentono al plug-in di aggiungere le proprie voci di menu, modificare la modalità di visualizzazione dei file, visualizzare le proprie informazioni nei pannelli appropriati, ecc. Poiché le dipendenze vengono passate dall'interfaccia, le implementazioni possono cambiare e le modifiche non interromperanno codice fintanto che il contratto rimane intatto.

All'epoca, veniva utilizzato un metodo factory per creare i plug-in utilizzando le informazioni di configurazione, la riflessione e l'oggetto Activator (almeno in .NET). Oggi esistono strumenti, MEF per uno, che consentono una gamma più ampia di opzioni durante l'iniezione di dipendenze, inclusa la possibilità per un framework di applicazioni di accettare un elenco di plugin come dipendenza.

Sommario

Mentre questi concetti possono essere utilizzati e offrire vantaggi in modo indipendente, insieme consentono di scrivere codice molto più flessibile, riutilizzabile e testabile. In quanto tali, sono concetti importanti nella progettazione di soluzioni orientate agli oggetti.

Buon articolo per comprendere IOC e DI http://martinfowler.com/articles/injection.html

IOC (Inversion of Control)

CIO significa

1. codifica per interfaccia (un componente dovrebbe dipendere dall'interfaccia dell'altro componente e non dall'impl), ad es

   interface iComp_2 {...}
   
   class Comp_1 {
       iComp_2 c2 = ….;
   }
   

2. rimozione del codice specifico di implementazione del componente es

   Comp_1 {
       iComp_2 c2 = getComp_2_Impl(); // not new Comp_2_Impl();
   }
   

Il COI può essere ottenuto in uno dei seguenti modi:

1. DI (Iniezione delle dipendenze)

3 types of DI

1.1 Constructor Injection

1.2 Setter Injection

1.3 Interface Injection

2. Localizzatore di servizi

Contenitore DI (Dependency Injection)

Determinazione impl di runtime e non tempo di compilazione: determina in fase di runtime quale implementazione concreta di un'interfaccia da utilizzare in base ad un file di configurazione (quindi al momento della compilazione non sappiamo quale impl verrà utilizzato e quindi aumenta la configurabilità dell'applicazione) . È un'implementazione in cui la relazione concreta tra i diversi moduli viene decisa in "fase di esecuzione".

Istantanea di impl dopo l'iniezione di dipendenza: dopo aver determinato l'impl, istanzia quell'implosione creando prima tutte le sue dipendenze (specificate nel file di configurazione) e quindi iniettando quelle dipendenze in quell'impl

Gestione del ciclo di vita delle istanze: i contenitori DI di solito conservano solo un riferimento agli oggetti per i quali è necessario gestire i cicli di vita o che vengono riutilizzati per iniezioni future, come singoli o pesi volanti. Quando configurato per creare nuove istanze di alcuni componenti per ogni chiamata al contenitore, il contenitore di solito dimentica solo l'oggetto creato. Altrimenti il ​​garbage collector avrebbe difficoltà a raccogliere tutti questi oggetti quando non vengono più utilizzati.

Direi che "Inversion of Control" è un modo per progettare un sistema in cui tutti i moduli sono pensati come entità astratte.

Inoltre, "Dependency Injection" è un'implementazione in cui la relazione concreta tra i diversi moduli viene decisa in "fase di esecuzione".

L'inversione del controllo è un concetto generale, nei linguaggi funzionali viene di solito fatto usando continuazioni. Questo ti consente di scrivere un'API in cui entrambe le parti sono "chiamante" e nessuna "chiamata". In altri ambienti più statici non hai questa facilità, quindi hai bisogno di questo trucco per inserire suggerimenti nel flusso di controllo.