Contract-First-Design and Dependency Injection ( Microkernel )
by David Hayden ( Florida .NET Developer )
A few weeks ago I talked about Dependency Injection Tools as a way to remove service locator and factory classes from my code:
Although I have heard of dependency injection, inversion of control, and other related topics for some time, that was my first time using a dependency injection tool to provide the loose-coupling desired in many of my applications.
Today I had a chance to read a blog post by Ralf Sudelbücher, entitled Dynamic component binding made easier - An easy to use Microkernel to help reap Contract-First-Design benefits in .NET programs. Ralf describes the use of a Microkernel ( depedency injection like ) as a means to support Contract-First-Design. I think the post is excellent and worth the time to read if you need or would enjoy a primer on dynamic binding of concrete services that implement contracts.
I, honestly, didn't know what Contract-First-Design meant until I read Ralf's post. He mentioned it as such:
“CFD views software as consisting of components. To avoid any heated discussion on what this term could possibly mean, let me try a very practical explanation: Think of a component as an assembly or a set of related assemblies. This assembly (or set of assemblies) you want to use together with other components to build a software solution.“
he further mentions the following:
“... So just think: Components encapsulate some functionality I want to separate from other functionality in other components.“
Dependency-Inversion Principle
Sounds like I have been using Contract-First-Design for quite some time, because it is essentially good use of the Dependency-Inversion Principle in object-oriented programming as I discuss in the following post:
The Dependency-Inversion Principles states that:
- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend on details. Details should depend on abstractions.
If you look at the code I just mentioned in the previous post, Active Record To Domain Objects and Data Access Objects - Data Access Design Patterns, and shown below, you will see that my CustomerDAO is not dependent on a concrete class that implements IDatabase, but the contract IDatabase. CustomerDAO itself implements a contract, ICustomerDAO, that is consumed by a client that uses the ICustomerDAO service - yet has no clue the concrete class, CustomerDAO, exists or will be the provider of the service.
You can get crazy with this loose-coupling if it is based upon “speculative design“ and you are adding extension points where no extension is necessary, but in general, loose-coupling and Contract-First-Design is a nice quality in your applications. As Ralf so eloquently puts it, it allows you to develop components independent of one another in parallel as well as offers great testability through mocks and stubs.
public class CustomerDAO : ICustomerDAO
{
private IDatabase _database;
public CustomerDAO()
{
_database = DatabaseFactory.CreateDatabase();
}
public CustomerDAO(IDatabase database)
{
Validation.AssertIsNotNull(database);
_database = database;
}
public Customer FindById(...)
{
...
}
public int Save(Customer customer)
{
...
}
public int Update(Customer customer)
{
...
}
public int Delete(Customer customer)
{
...
}
public Customer FindByEmailAddress(...)
{
...
}
public CustomerCollection FindByState(...)
{
...
}
}
Source: David Hayden ( Florida .NET Developer )
Filed: Design Patterns