Inject Dependencies
Note: This post is part of the series Lessons (re)learned.
When writing software following the object-oriented paradigm, dependency injection remains one useful technique, regardless of language.
As mentioned in the post titled Reduced Integration Surface, managing dependencies is key to sustainable software development. One practice that helps us better do that is to separate construction logic from business logic. Usually, construction takes place in the software entry point, where we declare and wire up the entire dependency graph.
One interesting effect of injecting dependencies is that it makes them explicit. In turn, we get better insights on the levels of abstraction and code smells, such as data clumps and feature envy.
Applied properly, dependency injection gives us better modularity and helps us abide by the dependency inversion principle.
Alistair Cockburn, on a talk named Hexagone, suggests that we call this property configurable dependency (which he attributed to Gerard Meszaros) instead. His rationale is that the name dependency injection encourages doing it wrong first and then flipping and fixing it.
Back in 2008, Miško Hevery gave a series of talks at Google. In one in particular, titled Global State and Singletons, Miško debunks common misconceptions in the Q&A section.