Dependency injection is een ontwerptechniek waarbij een stuk code de dingen waarvan het afhankelijk is van buitenaf krijgt aangereikt, in plaats van ze zelf te bouwen. Heeft een class een databaseverbinding of een mailservice nodig, dan worden die aangeleverd in plaats van intern gemaakt. Het is een praktische manier om de SOLID-principes te volgen en een codebase soepel te houden.
Denk aan een koffiemachine. Een goedkope heeft de molen, het verwarmingselement en het waterreservoir er muurvast ingebouwd, dus als de molen kapotgaat is de hele machine afval. Een beter ontwerp neemt cups die je van buitenaf inschuift, zodat je de koffie wisselt zonder aan de machine te komen. Dependency injection werkt net zo: de code zegt ‘geef me iets dat mail verstuurt’ en accepteert wat past, in plaats van één specifieke service erin te lassen.
Die losse koppeling betaalt zich vooral terug bij het testen. Omdat de code alleen om een interface vraagt, voer je hem tijdens tests een nepmailservice en in productie de echte, zonder iets te herschrijven. Veel frameworks hebben een container die deze stukken voor je aan elkaar knoopt.
Gratis is het niet. Een class die in zijn constructor om tien dingen vraagt, is vaak een teken dat hij te veel doet, en een container die alles als bij toverslag aanlevert, maakt het soms juist lastiger te zien waar een object vandaan kwam. De techniek verdient zichzelf terug als onderdelen echt verwisseld of los getest moeten worden, niet als je hem uit gewoonte overal overheen strooit.
Bij TopDevs leunen we op dependency injection zodat systemen van klanten makkelijk te testen en te wijzigen blijven, wat de kosten van nieuwe functies laag houdt naarmate de software groeit.
