Free Yourself with a Dependency Injection Container
I'm now doing a column for MSDN magazine about how design patterns help developers solve typical business problems. The column is called "Patterns in Practice", but it could just as easily have been called "Thinking with Objects." As I was writing this month's Patterns in Practice column, I was thinking about how much easier my life has become since I've started using Inversion of Control (IoC)/Dependency Injection Containers. But when, as a consultant, I work with other developers, I find that these tools aren't all that common.
The issue is that, once you start thinking in terms of "What objects would make it easy to solve this problem?", you can end up with a few, very complicated objects. A better solution is to have lots of very simple objects that you can instantiate as you need them. With this approach, you end up with many variations on a single class, with each of those variations designed to do a great job of handling a specific problem.
The problem is that dealing with those objects can be a nightmare. If, for instance, you have three different Customer classes (each designed to handle one kind of customer), you can end up with three different variable declarations:
Dim custp As PremiumCustomer
Dim custOrd As OrdinaryCustomer
Dim custDb As Deadbeat
Using inheritance or interfaces lets you make all the variations on a class look alike. The practical result is that you can declare one variable to work with all the varieties of the class. If all the Customer classes inherit from one class or implement the same interface, you can declare a single variable to work with any Customer object. Here's the only variable declaration you need if all Customer classes implement the same interface, ICustomer:
Dim cust As ICustomer
The problem is the New statements; those statements have to reference a specific class:
cust = New PremiumCustomer
cust = New OrdinaryCustomer
cust = New PremiumCustomer
What a Dependency Injection Container does is eliminate those New statements. Instead, you load the container with the objects your application needs. When you want a class, you just turn to the container and ask for it. You can even specify criteria to choose which object you want. Code like this works with Microsoft's Unity container, for instance, to find an object that implements the ICustomer interface and is associated with the string "Premium":
cust = DependencyContainer.Resolve<ICustomer>("Premium")
Really, these tools solve a ton of problems and can completely change the way you think about objects when solving problems.
Posted by Peter Vogel on 04/30/2013