Ottima spiegazione dell'iniezione di dipendenza (inversione del controllo)

Ho letto molte spiegazioni su Dependency Injection o DI (precedentemente noto come Inversion of Control) e sul principio Hollywood associato ("Non chiamateci, ti chiameremo"). Tendono tutti a non essere chiari, o perché approfondiscono immediatamente spiegazioni molto dettagliate, o legano la spiegazione specificamente a una particolare tecnologia. Tale che o si perde il modello o lo è la sua semplicità. Ecco la spiegazione più chiara che ho trovato - leggermente modificata per brevità (dall'ottimo Spring in Action, 2nd. Ed. Di Craig Walls):

"Qualsiasi applicazione non banale è composta da due o più classi che collaborano tra loro per eseguire una logica di business. Tradizionalmente, ogni oggetto è responsabile di ottenere i propri riferimenti agli oggetti con cui collabora (le sue dipendenze). Quando si applica DI, il agli oggetti vengono date le loro dipendenze al momento della creazione da qualche entità esterna che coordina ogni oggetto nel sistema. In altre parole, le dipendenze vengono iniettate negli oggetti. "

Lo trovo molto chiaro.

L'inserimento delle dipendenze era originariamente chiamato Inversion of Control (IoC) perché la normale sequenza di controllo sarebbe che l'oggetto trova gli oggetti da cui dipende da solo e quindi li chiama. Qui, questo è invertito: le dipendenze vengono passate all'oggetto quando viene creato. Questo illustra anche il principio di Hollywood al lavoro: non chiamare in giro per le tue dipendenze, te le daremo quando avremo bisogno di te.

Se non usi DI, probabilmente ti starai chiedendo perché è un grosso problema. Offre un vantaggio chiave: accoppiamento libero. Gli oggetti possono essere aggiunti e testati indipendentemente da altri oggetti, perché non dipendono da nient'altro che da ciò che passi loro. Quando si utilizzano le dipendenze tradizionali, per testare un oggetto è necessario creare un ambiente in cui tutte le sue dipendenze esistano e siano raggiungibili prima di poterlo testare. Con DI, è possibile testare l'oggetto in isolamento passandogli oggetti fittizi per quelli che non si desidera o non è necessario creare. Allo stesso modo, l'aggiunta di una classe a un progetto è facilitata perché la classe è autonoma, quindi questo evita la "grande palla di pelo" in cui spesso evolvono i grandi progetti.

La sfida di DI sta scrivendo un'intera applicazione che la utilizza. Alcune lezioni non sono un grosso problema, ma un'intera app è molto più difficile. Per intere applicazioni, spesso si desidera un framework per gestire le dipendenze e le interazioni tra gli oggetti. I framework DI sono spesso guidati da file XML che aiutano a specificare cosa passare a chi e quando. Spring è un framework Java DI a servizio completo; altri framework DI più leggeri includono NanoContainer e l'ancor più leggero PicoContainer.

La maggior parte di questi framework ha buoni tutorial per aiutare i principianti a trovare la loro strada.

Questa storia, "Excellent Explanation of Dependency Injection (Inversion of Control)" è stata originariamente pubblicata da JavaWorld.