In che modo l'inversione del controllo è correlata all'inversione delle dipendenze

In molti articoli in tutto il web i termini Inversione del controllo e dipendenza Principio di inversione sembrano essere confusi e usati come sinonimi (ulteriore confusione è imposta dagli strumenti che sono chiamati "DI-Containers" e "IoC-Containers"). Un articolo di Wikipedia fa un buon lavoro cercando di spiegare che l'IoC non è lo stesso di DI:

inversion of control (IoC) descrive un progetto in cui porzioni scritte personalizzate di un programma per computer ricevono il flusso di controllo da una libreria generica e riutilizzabile

Quindi DIP consiste nel far dipendere i moduli dalle astrazioni piuttosto che dalle implementazioni concrete.

E l'IoC consiste nel dare il controllo del flusso del programma a un modulo separato. E una delle cose che puoi fare con questo modulo è risolvere le dipendenze in fase di esecuzione.

Questa differenza sembra giusta, ma non ho mai visto nessuno menzionare altre applicazioni del principio IoC diverse dalla risoluzione delle dipendenze. La definizione di Wikipedia è piuttosto ampia e sembra che potresti fare molto di più con un modulo che può effettuare chiamate nel tuo codice personalizzato in base alla sua configurazione e ad alcune logiche interne.

Quindi, ecco alcune domande che non riesco ancora a capire:

Qual è la relazione effettiva tra IoC e DIP? L'IoC è sempre il mezzo per implementare il DIP?
Perché gli strumenti per la risoluzione delle dipendenze sono chiamati contenitori DI e IoC? Ciò implica che DI e IoC sono la stessa cosa.

Nota : questa domanda non è un duplicato di Qual è la differenza tra DI e IoC , poiché quest'ultimo chiede informazioni sull'iniezione delle dipendenze, non sull'inversione delle dipendenze.

design-patterns inversion-of-control dependency-inversion

— Andre Borges
fonte

Possibile duplicato di Qual è la differenza tra DI e IoC?

— moscerino il

@gnat, no non lo è, per favore vedi la mia modifica

— Andre Borges

d'accordo, mi sono perso quella scusa

— moscerino

IMO, la risposta semplice è "sono uguali". IoC è un altro nome per l'inversione di dipendenza ed entrambi sono un modo per ottenere l'iniezione di dipendenza. Vedo "inversione di dipendenza" come un termine profondamente inutile in quanto troppo facilmente confuso con l'iniezione. Quindi c'è DI (iniezione) e l'IoC è un modo per ottenere l'inversione delle dipendenze / controllo tramite l'iniezione.

— David Arno,

C'è un grande articolo sul sito di Martin Fowler che contiene un capitolo specifico sulla differenza tra DIP, DI e IoC . L'essenziale (come copiato da quel sito) è

DI è su come un oggetto acquisisce una dipendenza. Quando una dipendenza viene fornita esternamente, il sistema utilizza DI. IoC riguarda chi avvia la chiamata. Se il tuo codice avvia una chiamata, non è IoC, se il contenitore / sistema / libreria richiama il codice che hai fornito, è IoC.

DIP, d'altra parte, riguarda il livello di astrazione nei messaggi inviati dal tuo codice alla cosa che sta chiamando. A dire il vero, l'uso di DI o IoC con DIP tende ad essere più espressivo, potente e allineato al dominio, ma riguardano dimensioni o forze diverse in un problema generale. DI è per il cablaggio, IoC per la direzione e DIP per la forma.

— JDT
fonte

IoC parla di chi avvia la chiamata - a chi ha assegnato la chiamata a cosa? Se scrivo ISomeInterface object = container.Resolve<ISomeInterface>()quell'IoC o no?

— Andre Borges

Quello che scrivi è un'implementazione nel modello di localizzazione del servizio. Questo è anche IoC. Non IoC è oggetto ISomeInterface = new MyClass (). Quindi la chiamata che si intende è la "chiamata all'istanza" (o chi chiama "nuovo").

— Sjoerd222888

"DIP, d'altra parte, riguarda il livello di astrazione nei messaggi inviati dal tuo codice alla cosa che sta chiamando." Mi sembra una sciocchezza. Dov'è l'inversione in questo? Descrive l'astrazione della dipendenza, non l'inversione.

— David Arno,

@DavidArno, stai dicendo che non possiamo fidarci del sito Web di Martin Fowler?

— Holdenmcgrohen,

@holdenmcgrohen, sono le sue opinioni sulle cose. Solo perché è Martin Fowler, non è un dato di fatto. A volte ha torto l'IMO, per esempio riguardo al "modello di dati sull'anemia". Altre volte, è molto penetrante. In questa occasione penso che abbia sbagliato anche lui perché non ha senso.

— David Arno,