Jeg har lest mange forklaringer på Dependency Injection eller DI (tidligere kjent som Inversion of Control) og det tilhørende Hollywood-prinsippet ("Don't call us, we call you."). De har alle en tendens til å være uklare, enten fordi de går direkte inn i svært detaljerte forklaringer, eller de knytter forklaringen spesifikt til en bestemt teknologi. Slik at enten mønsteret er tapt eller dets enkelhet er. Her er den klareste forklaringen jeg har funnet - litt redigert for kortfattethet (fra den veldig gode Spring in Action, 2. utg. Av Craig Walls):
"Enhver ikke-applikasjon består av to eller flere klasser som samarbeider med hverandre for å utføre noe forretningslogikk. Tradisjonelt er hvert objekt ansvarlig for å skaffe sine egne referanser til objektene det samarbeider med (dets avhengigheter). Når du bruker DI, objekter får sin avhengighet ved opprettelsestidspunktet av en ekstern enhet som koordinerer hvert objekt i systemet. Med andre ord blir avhengigheter injisert i objekter. "
Det synes jeg er veldig tydelig.
Avhengighetsinjeksjon ble opprinnelig kalt Inversion of Control (IoC) fordi den normale kontrollsekvensen ville være at objektet finner gjenstandene det er avhengig av av seg selv og deretter kaller dem. Her er dette omvendt: Avhengighetene blir gitt til objektet når det er opprettet. Dette illustrerer også Hollywood-prinsippet på jobben: Ikke ring for dine avhengigheter, vi gir dem til deg når vi trenger deg.
Hvis du ikke bruker DI, lurer du sannsynligvis på hvorfor det er en stor avtale. Det gir en viktig fordel: løs kobling. Objekter kan legges til og testes uavhengig av andre objekter, fordi de ikke er avhengige av noe annet enn hva du sender dem. Når du bruker tradisjonelle avhengigheter, for å teste et objekt må du opprette et miljø der alle dets avhengigheter eksisterer og er tilgjengelige før du kan teste det. Med DI er det mulig å teste objektet isolert ved å gi det spotte objekter for de du ikke vil eller trenger å lage. På samme måte blir det lagt til en klasse til et prosjekt fordi klassen er selvstendig, så dette unngår den "store hårballen" som store prosjekter ofte utvikler seg til.
Utfordringen med DI er å skrive en hel applikasjon ved hjelp av den. Noen få klasser er ikke så farlig, men en hel app er mye vanskeligere. For hele applikasjoner vil du ofte ha et rammeverk for å administrere avhengighetene og interaksjonen mellom objekter. DI-rammer drives ofte av XML-filer som hjelper med å spesifisere hva du skal overføre til hvem og når. Våren er et fullservice Java DI-rammeverk; andre lettere DI-rammer inkluderer NanoContainer og den enda lettere PicoContainer.
De fleste av disse rammene har gode opplæringsprogrammer som hjelper nybegynnere å finne veien.
Denne historien, "Excellent Explanation of Dependency Injection (Inversion of Control)" ble opprinnelig utgitt av JavaWorld.
