In my previous post, I talked about Dependency Injection (DI). One implementation of DI is using interface-oriented design to abstract a class from an injected dependency via an interface. This is one possible implementation of the Bridge pattern. Depending only upon an interface and classes to implement that interface opens up some very interesting possibilities.
The tried-and-true means of creating an object is to simply directly use it’s constructor, for example:
IPerson person = new Employee(“Peter”, “Ritchie”);
This is nice and simple; but we’re still coupled to Employee despite using an IPerson object thereafter. The above code hasn’t truly eliminated the dependency upon the Employee class. Moving all that type of logic to a single method encapsulates the logic into one, reusable, place. This is the Factory pattern, for example:
person = Person.Create(“Peter”, “Ritchie”);
The Create method, a “Factory Method” on a concrete (likely static) class Person, would know how to create an IPerson object. At this point using a IPerson object is completely abstracted from a specific concrete type and its creation.
InviteToMeeting(person);
InviteToMeeting is completely independent of the concrete type implementing IPerson (and it can actually be a private type) and how it was created or where it came from. This abstraction leaves IPerson objects free to be created however they need to be. The benefits of Dependency Injection, Bridge, and Factory patterns are synergistic–together they offer more than if they were apart. In the above example they’re created as Employee objects; but because their creation is completely encapsulated it could also be affected by policy. Policy that clients of the factory would have no dependency upon.
In the simplest case Person.Create could always just create Employee objects; but because creation is hidden from the client the factory method could use other logic to decide what classes to use. Person.Create could be implemented this way:
public static IPerson Create ( String firstName, String lastName )
{if (Configuration.IsAdministrator)
{return new Employee(firstName, lastName);
}
else {return new Subordinate(firstName, lastName);
}
}
Now we’re injecting policy into the creation process. Somewhere, likely not in source code, whether the current user is running as an administrator. This state is used in a policy to decide what type of IPerson object to create.
> The above code hasn’t truly eliminated the dependency upon the Employee class. Moving all that type of logic to a single method encapsulates the logic into one, reusable, place. This is the Factory pattern, for example:
You haven’t eliminated the dependency on Employee at all, you have just added a dependency to Person.
> In the simplest case Person.Create could always just create Employee objects; but because creation is hidden from the client the factory method could use other logic to decide what classes to use. Person.Create could be implemented this way:
Alternately you could use one object for both Employee and Subordinates and encapsulate the differences.
It seems to me the need for factory methods implies that your class hierarchy is poorly designed.
There, of course, a dependency on a utility class Person; but the code no longer uses Employee directly. It now uses a method that is less likely to change over time,allowing Employee to change independently of the code that uses the variable “person”.
This is code dependency, obviously deploying that code requires deploying the Employee class so there is a dependency upon the Employee class; but not at the code level.
See http://www.theserverside.net/tt/articles/showarticle.tss?id=ControllingDependencies and http://en.wikipedia.org/wiki/Bridge_pattern for more information.
I’m a big fan of dependency injection, although i have to admit i find the term a bit ‘fowlerbot’.
I tend to go a level more removed than this though, so rather than having the methods as static factory methods on the objects themselves, have a configurable service container which allows service interfaces to be retrieved, and then use the service to return the appropriate objects.
It probably depends what type of code you’re developing. For frameworks then the example you’ve posted is more common (e.g. the System.Security.Cryptography namespace which makes heavy use of this pattern) whereas for app it’s more likely to be a service container.
A blog needs a simple example, so putting it on the class as a static member makes for better reading to a certain extent.
But yes, depending on how the object needs to be created (in that what is needed to into the creation of the object is outside of the responsibility of the class) another class is often more appropriate.
I was ramping up to something like that in a future post on repositories; but it wouldn’t be limited to repositories.
There is a Java framework called Guice that allows you to separate interface and implementation even further away, using annotations and an Injector object.
An overview can be found here:
http://docs.google.com/Doc?id=dd2fhx4z_5df5hw8
Is there something equivalent to Guice on .Net?
—
Cedric
As far as I know there is no Guice.NET yet. There are lots of dependancy injection frameworks (or frameworks that include DI) for .Net though:
Unity [1]
Spring.Net [2]
StructureMap [3]
Windsor [4] (part of Castle, which is like Spring.NET)
Etc…
[1] http://www.codeplex.com/unity
[2] http://www.springframework.net/
[3] http://structuremap.sourceforge.net/Default.htm
[4] http://www.castleproject.org/container/index.html
A wnoedrful job. Super helpful information.