DevDirective

Introduction

If you happen to be working in a statically typed language, there's a pretty good chance you'll have brushed up against Dependency Injection or the Dependency Inversion Principle. The former has led to many frameworks that have sprouted up making this easier to achieve in a static language, whereas dynamic languages like Ruby don't really need the frameworks. The Principle, however, still applies in order to achieve good software.

You just have to do a basic search to come up with a plethora of links to information on the topic, and yet many developers are still no closer to grokking it. So we've scoured a few places and tried to make the filter slightly more geared towards understanding what it means, and when to use it.

So without further ado, let's see what the experts have to say when we take a good hard look at Dependency Injection and Inversion:

Firstly, let's make sure we've all of our definition ducks in a row. Many developers tend to use these two terms interchangeably when they should be using one or the other. Derick Bailey has noticed this problem too, and has published this excellent post which is mostly an excerpt from his outstanding previously written CODE Magazine article.

The basic premise boils down to this:

1. Dependency Inversion Principle is a pattern which seeks to decouple a module that defines and uses a specific Policy, from a module that defines the Details of implementation, and making the Details depend on the Policy. Having it the other way around is all too common, and creates many of our problems in every day software development.
2. Dependency Injection is also a pattern, a complimentary one if you like, describing means by which a module obtains an instance of a dependency it needs in order to perform its function. While that is demonstration of loose coupling to a certain extent, it is entirely possible for your code to use Dependency Injection to push a Policy module into the constructor of a Details module, and still violate Dependency Inversion because the dependency is pointing in the wrong direction.

While you're at it, don't forget to take a look at two more very good posts by Derick on the subject that might help pierce the fog:

1. Dependency Inversion: ‘Abstraction’ Does Not Mean ‘Interface’
2. DI and IoC: Creating And Working With A Cloud Of Objects

Ah - just what we needed. Kevin Pang has provided the perfect introduction if you're really lost, or just haven't ever come across the concepts. This is absolutely possible, and I've met many developers who have been writing code for the last five years, and have never heard of the terms.

And you know what? That's totally fine because as long as you're willing to learn, there's someone willing to teach, and Kevin does exactly that in this short and sweet post that'll get you going with the basics.

If that wasn't enough for you, and just left you with a thirst for more, but you still want more of the beginners' touch, have a look at Billy McCafferty's more detailed and very practical introduction.

He covers everything from the motivations for use and how they came about through building up a simple service to show how each of the concepts has its place and gives a very well rounded account of the slightly more in-depth concepts of Inversion of Control containers.

This text was written by Karl Seguin a fairly long time ago as part of his free Foundations of Programming e-book, but it's one of those pieces of writing that stands the test of time - at least as far as statically typed languages are concerned, but I would venture more than that too.

Karl is outlining some further concepts in his second edition of the book which is still a work in progress, but looks very interesting nonetheless. He still comes back to the same concepts as many others in this well written piece - reducing coupling between modules is key to a flexible and maintainable design.

No discussion or review of patterns would be complete these days (or before) without significant input from Uncle Bob Martin it seems. One of the canonical pieces of work on the subject, his PDF tends to be the go-to guide for those more technically inclined.

This article is not for the faint of heart, to be sure, but if you're looking for something to file alongside the technical documentation for your architecture, you'd do well to include this one. It covers everything from the initial premise, through to example and possible expansions on the idea.

Another luminary in the patterns space is none other than Martin Fowler himself, and I would be remiss if I didn't include his work here. Written back in 2004, this article is literally the soup to nuts version and covers pretty much everything you need to know about this pattern.

On the down side, it is very long and more akin to reading a chapter of a book rather than a post on the subject. The other problematic part is that certain pieces of the work have started to show some cracks over time and use, for example, the Service Locator pattern described in the text is now widely accepted by many as an anti-pattern and that developers should steer clear of using it. That doesn't mean that Dependency Injection becomes a bad idea, just as with all things, there are good ways and bad ways of doing it.

If there is someone whose brains you'd want to pick on the subject, somewhere at the top of the list would have to be Mark Seemann. He has quite literally written the book on the subject as it pertains to .NET, and many of the same ideas hold true in other statically typed languages such as Java.

Mark is passionate about the topic, and his teaching style is straight forward and to the point. It's exactly what you need when dealing with something like this. There are too many fluffy opinions out there to muddy the waters, but if you're looking to get a good understanding of the good and the bad, then this is where you want to start looking.

Oh - and I would highly recommend buying his book should you be delving in deep. It is a quality read.

Conclusion

When it comes to statically typed languages, after the hard and often painful lessons we've learned over the last few years, there can be no doubt that making use of this technique will make for more robust and maintainable code. In addition, we also know that using a container is pretty much a given if at all possible in order to remove as much boiler plate code as possible.

I hope this has provided an insight for you to take this idea further and please do let me know if you've stumbled across an excellent resource yourself that you'd like me to include and I'll gladly do so with credit to you for the find!

Until next time,
RobertTheGrey