Jeg har læst mange forklaringer på Dependency Injection eller DI (tidligere kendt som Inversion of Control) og det tilknyttede Hollywood-princip ("Ring ikke til os, vi ringer til dig."). De har alle en tendens til at være uklare, enten fordi de straks dykker ned i meget detaljerede forklaringer, eller de binder forklaringen specifikt til en bestemt teknologi. Sådan at enten mønsteret går tabt eller dets enkelhed er. Her er den klareste forklaring, jeg har fundet - let redigeret for kortfattethed (fra den meget gode Spring in Action, 2. udgave af Craig Walls):
"Enhver ikke-applikation består af to eller flere klasser, der samarbejder med hinanden for at udføre en vis forretningslogik. Traditionelt er hvert objekt ansvarligt for at opnå sine egne referencer til de objekter, det samarbejder med (dets afhængigheder). Når DI anvender, objekter får deres afhængigheder ved oprettelsestidspunktet af en ekstern enhed, der koordinerer hvert objekt i systemet. Med andre ord injiceres afhængigheder i objekter. "
Det finder jeg meget klart.
Afhængighedsinjektion blev oprindeligt kaldt Inversion of Control (IoC), fordi den normale kontrolsekvens ville være, at objektet finder de objekter, det afhænger af, af sig selv og derefter kalder dem. Her er dette omvendt: Afhængighederne overdrages til objektet, når det oprettes. Dette illustrerer også Hollywood-princippet på arbejdspladsen: Ring ikke rundt for dine afhængigheder, vi giver dem til dig, når vi har brug for dig.
Hvis du ikke bruger DI, undrer du dig sandsynligvis over, hvorfor det er en big deal. Det giver en nøglefordel: løs kobling. Objekter kan tilføjes og testes uafhængigt af andre objekter, fordi de ikke afhænger af andet end hvad du sender dem. Når du bruger traditionelle afhængigheder, skal du oprette et miljø, hvor alle dets afhængigheder findes og kan nås, før du kan teste det, for at teste et objekt. Med DI er det muligt at teste objektet isoleret ved at sende det mock-objekter til dem, du ikke vil eller har brug for at oprette. Ligeledes er det lettere at tilføje en klasse til et projekt, fordi klassen er selvstændig, så dette undgår den "store hårbold", som store projekter ofte udvikler sig til.
DI's udfordring er at skrive en hel applikation ved hjælp af den. Et par klasser er ikke så farligt, men en hel app er meget sværere. For hele applikationer ønsker du ofte en ramme til styring af afhængigheder og interaktioner mellem objekter. DI-rammer er ofte drevet af XML-filer, der hjælper med at specificere, hvad der skal overføres til hvem og hvornår. Spring er et Java DI-framework med fuld service; andre lettere DI-rammer inkluderer NanoContainer og den endnu mere lette PicoContainer.
De fleste af disse rammer har gode tutorials, der hjælper begyndere med at finde vej.
Denne historie, "Excellent Explanation of Dependency Injection (Inversion of Control)" blev oprindeligt udgivet af JavaWorld.
