Code As Dependency Configuration

re: Code As Dependency Configuration

Udi Dahan — Wed, 30 May 2007 20:58:30 GMT

Given that you're top level assembly has all the required concrete dependencies in order to use code instead of configuration, you could still call into something like Spring.net. (I'm just using your preconditions for code to work, in order to rebutt your "doesn't copy to output directory" argument.)

There's also runtime object creation that DI frameworks provide, that are incredibly useful in scenarios like the one described here:

http://udidahan.weblogs.us/2007/04/30/generic-validation/

You still haven't solved the abstract factory issue with your code example. For instance, how would you do:

spring.GetObjectsOfType(typeof(IValidator<Customer>));

To get all the classes which should validate your customer object.

Other than that, I agree that code, with its intellisense support is probably more convenient than XML for wiring dependencies.

re: Code As Dependency Configuration

ploeh — Thu, 31 May 2007 10:42:14 GMT

Hi Udi

Thank you for your comments.

The point of this post was not to claim that Spring.NET doesn't support this technique, but just to describe the benefits of Code As Configuration. The reason I mentioned Spring.NET was just because this is a relatively well-known framework that (also) supports the XML configuration option, with the advantages and disadvantages this entails.

I totally agree that you could use Spring.NET or other DI frameworks to achieve the same effect as the one I was aiming for - I just didn't want to make knowledge of a particular framework a precondition for reading the post, which is why I used Constructor Injection in my example.

In this post, however, I wasn't trying to solve the Abstract Factory issue at all :)

In the example outlined, an Abstract Factory shouldn't be allowed at all; if you want a list of IValidator<Customer>, you should take an instace of IList<IValidator<Customer>> as a constructor parameter. That's just the approach taken in this sample, and I'm not saying that you shouldn't use Abstract Factory at all, but for code consistency, I think it's a good idea to stick with a single strategy - either Constructor Injection, or Abstract Factory, or something else. In fact, my favorite is Provider Injection.

When used for DI, Abstract Factory is very similar to Service Locator. Although I've been very fond of Service Locator in the past, these days I prefer Constructor or Provider Injection, because these patterns lets the API communicate intent more clearly. Maybe I should write a separate blog post on this subject?

re: Code As Dependency Configuration

Mike D — Thu, 31 May 2007 16:34:37 GMT

I know this is a little OT, but it does apply to constructor injection.

My question is why not have interfaces that support construtor contracts? Perhaps there is some deep reasoning and the universe might explode or there are other problems with this, but I have seen many instances where this would be useful.

re: Code As Dependency Configuration

ploeh — Thu, 31 May 2007 17:18:58 GMT

Hi Mike D

Thank you for asking - although the universe will not explode, our solar system might disintegrate if we do something like this :)

Joking aside, there are at least two answers to that question: One having to do with practical constrains, and one having to do with design and architecture.

Let's do the first one first:

Interfaces don't support the modelling of constructors, and public constructors in abstract classes don't make any sense, so pure constructors are out of the question. Then what about factory methods? Well, there's actually the Abstract Factory design pattern, which is probably the closest you can come to specifying a contract for object creation, but that still leaves the question of how to create the abstract factory itself.

Basically, there's no support for such things in the BCL.

From a design perspective, it also makes a lot of sense to separate object creation from object behavior. Consider my example in this post. ClassC uses Abstraction5 which is supplied to it in its constructor. ClassB incidentally uses ClassC because it uses Abstraction3. Let's say that I wanted to change the hierarchy by replacing ClassC with a self-contained class (let's call it ClassCPrime). ClassCPrime doesn't consume Abstraction5, so it only exposes a default constructor. In other words, ClassC's constructor has a different signature than the constructor of ClassCPrime. This is what allows me to dramatically change the service hierarchy in the example.

To extend this further, you may have some service implementations that are actually Singletons. Since we are not making any assumption on how objects are created, we could perfectly well pass a Singleton as a parameter for a class that uses Constructor Injection.

This flexibility is very powerful, and that's why we don't have interfaces that specifies how implementations are created.

This subject is rather complex and could actually benefit from a more thorough treatment, including code examples and illustrations, but I hope I managed to answer your question to at least some extent; otherwise, feel free to ask again.

re: Code As Dependency Configuration

Mike D — Fri, 01 Jun 2007 09:04:25 GMT

Thanks for taking the time to explain, and actually I do get your point.

Whatever the technical term for hitting the wall is, I hit the wall all the time. I try and code my way out only to find myself in another corner.

DI is GOOD, however we have no means of explicitly defining a contract for dependencies. We can define a contract for behavior.

Everytime I find myself in this place, jumping through hoops, to do what seems to be a simple task, I can't help wonder are we missing the forest for the trees.

Yes you answered my question well in the context of the example, I see the mess interface constructors could create.

What if there were a way to specify that contract A requires contract B without the hoops?

I really like your blog and would like to see more on decoupling layers.

re: Code As Dependency Configuration

ploeh — Sat, 02 Jun 2007 11:13:33 GMT

Hi Mike

Thank you for your comments.

The reason why it's beneficial not to specify that Contract A requires Contract B is exactly because of decoupling.

My favorite example goes something like this: Imagine that you have on online shop with an Order class. To calculate discounts, the Order class calls into an abstract DiscountCalculator class, which is instantiated by DI in some way (pick your favorite DI technique).

Imagine that you have a database-backed DisountCalculator implementation that will look up discounts for specific products in the database. This DatabaseDiscountCalculator uses an abstract Data Access Component (DAC) to access the product discount data.

In essense, the Order class has a dependency on the DiscountCalculator 'contract', and the DatabaseDiscountCalculator has a dependency on the DAC 'contract'.

However, it wouldn't be a good idea to explicitly model that the DiscountCalculator 'contract' requires the DAC 'contract', because you may want to create another implementation of DiscountCalculator that uses, say, a web service instead of a database; or maybe one that uses a simple algorith to calculate discounts without any data access at all.

We wouldn't be able to model these extensibility configurations if we had required that DiscountCalculator requires the DAC (and only the DAC).

While there are good reasons for not doing it, it IS possible to specifiy that contract A requires contract B: Just create a method on contract A along the lines of:

public abstract ContracB GetContractB();

There are other scenarios where this design is valuable, but not for defining layered object hierarchies.

re: Code As Dependency Configuration

Mike D — Sat, 02 Jun 2007 15:12:17 GMT

Is there not a need for decoupling between the DC, DiscountCalculator, and the DAC/WS versions, where the discounts are stored is not it's concern. in other words each implementation of the DC would have it's own DI for which the order is unaware of.

IOrder requires IDiscountCalc

DACDiscountCalc requires IDataContext

WSDiscountCalc requires IWebServiceContext

DACDC implements IDiscountCalc

WSDC implements IDiscountCalc

IDiscountCalc dc =

DiscountFactory.Create() { DAC || WS }

IOrder o =

OrderFactory.Create(dc)

When I look at the DI techniques and can't help but think that the language is missing convention to handle this.

One good example is generics, when introduced much of the code we write started looking a feeling right. This pretty much eliminated the need for the ( new keyword as used in overloading ) due to the lack of conariant return types. While talking about generics, I just had the need for a new() constratint that would look like this:

<T>Create() : where T new(IDiscountCalc)

This is a generic method that can create an object that must have a dependency on IDiscountCalc. I had to resort do declaring an interface IDiscountCalcDependent.

<T>Create() : where T : IDiscountCalcDependent

Wouldn't it make more since if there were a language feature with compiler checks that allowed you to specify that A depends on B.

I totally get DI constructor and setter, both need to be there, I just see the problem as the language should allow you to specify a dependency.

Thanks for the discussion...

re: Code As Dependency Configuration

ploeh — Sun, 03 Jun 2007 00:25:14 GMT

Hi Mike

If I understand what you are saying, you are not talking about chaining dependencies together in contracts (that's what I thought at first), but rather that you wish to be able to explicitly state that a particular implementation (Order) needs an instance of a particular abstraction (DiscountCalculator)?

If this is the case, I can see that it quickly becomes quite complex when you take the Abstract Factory/Service Locator route.

On the other hand, such semantics are automatically expressed by Constructor Injection, which is one of the reasons I like this pattern better.

Your question inspired me to write a post about this subject - I'm not sure it answers your question, but I thought it was a worthwhile subject none the less :)

Please take a look and let me know if you think I understood your question :)

Fixture Setup With Installers

ploeh blog — Wed, 28 Nov 2007 17:00:38 GMT

It's no secret that I prefer unit tests over integration tests. Whenever it's possible to replace an

Testing Theories Part 2 - Unit Testing with Inversion of Control Pro's/Con's

Alec Lazarescu's Blog — Tue, 19 Feb 2008 01:39:56 GMT

Inversion of Control (IoC) is often achieved by Dependency Injection and programming to interfaces and

Modifying Behavior of WCF-Free Service Implementations

ploeh blog — Fri, 27 Jun 2008 23:55:52 GMT

In my previous post , I explained how to implement a WCF service without referencing WCF. In simple cases,

Unit Testing Duplex WCF Clients

ploeh blog — Wed, 09 Jul 2008 00:06:14 GMT

In my previous post , I explained how to unit test a WCF service with callbacks. Since the scenario involves

An Overview of Unit Testing Duplex WCF Services and Clients

ploeh blog — Sat, 12 Jul 2008 08:50:52 GMT

In the last couple of posts, I've demonstrated how to isolate implementation from WCF contract definition