A colleague of mine recently posted on an internal Slack channel about this blog article: How not to do dependency injection - the static or singleton container.

Reading the article, I became aware of something that a friend of mine had written about, namely the absolute vitriol that many coding blogs and generally good books seem to have against Service Location. For example, I’m reading Adaptive Code via C# at the moment and in that Gary McLean Hall has a small meltdown about it, which is a shame because it’s a pretty good book for people to learn about refactoring and use of basic patterns. However it also commits the cardinal sin of saying that the ‘D’ in SOLID is for Dependency Injection and not Dependency Inversion, and that betrays the architectural bias of the author.

The upshot being:

  • Anyone who tells you service location is an anti-pattern isn’t fully aware of the problems that it is supposed to be an answer for.
  • Dependency Injection moves away from the original point - separating the configuration of services from their use.
  • Dependency Injection vastly increases the surface area of an object via abuse of the constructor which isn’t bound by interface contract, thereby avoiding abstracting dependencies fully and leading to constructors being the medium by which relationships between objects are communicated - (this is not a virtue)
  • By making assumptions about state, Dependency Injection turns architectural uses-a relationships into has-a - which blocks the use of singletons and a bunch of other architectural patterns where they would be appropriate.
  • Further, it means that although relationships between data entities are modelled, behavioural relationships between objects are not because they become one great big dependency ball.

Guy Murphy - Service Locator vs Dependency Injection

Another in-depth article Guy wrote about Inversion of Control can be found here:

Guy Murphy - I come not to bury IoC, but to praise it