This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: IOC vs .Net, round 2
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Quite a lot of people got up in arms after my previous post about the decreased relevance of IOC (Inversion of Control) in .Net. I have to say that the provocation was somewhat intentional, but the logic is still sound. For those familiar with design based around IOC, it is clear that any dependencies between classes are broken by interfaces. The advantages in terms of testability and lower coupling are well known. I don't argue these points, but rather I think that they don't go far enough. Let's take as an example a class C1 that is dependent on interfaces I1, I2, and I3. Personally, I prefer constructor based injection to property injection, but it is irrelevant. The problem is always the null value. If for one of the interfaces we receive a null object, then we will be getting NullReferenceExceptions whenever code is run that uses that object. This is something of an annoyance when I only want to test one interaction, even though other interactions may be involved - I can't just pass in null. The other solution to the "null problem" is to have class C1 always test for null before using an object. I bet you can smell the stench half way across the 'net. Another issue is versioning/extensibility - if I want to have 2 objects of interface I1 in use for C1, well, I have to change my class. Consider wanting to both send voice-mail and email to a user as a result of something in C1. Both the voice-mail and the email implementation would implement the same interface. If it's true for 2, then it's true for 3, and K, so by induction we have an extensibility problem. The flip side is that once the class has been written for an arbitrary number of objects, the code that calls it needs to be aware of this. We're changing the code of the class because of factors totally external to it, this smells of a responsibility problem. In fact, wouldn't it be nice to take all this wiring between all our implementation classes and make it so that they wouldn't need to know about it, or be changed by changes in the wiring? This could be called making the class independent. Some would call this a component. I wouldn't get too hung up on definitions. It's just the evolution of the design. So, the question remains; HOW do we make our class C1 independent of I1, I2, and I3? Well, the answer is to look within our class. Why is it that we're calling the interfaces at these specific places in our code? In essence, we're notifying the outside world about things that are going on inside. In the example above with the email and voice-mail, class C1 is really trying to perform functionality that can be called "Notify User" by using the interfaces it has. Suppose that instead of knowing that C1 needs to call two instances of IUserNotifier, it would just raise...
Previous Topic
