Inversion of Control Pattern vs Dependency Inversion Principle

over 4 years ago | Matt Deiters: The Agile Developer

I was talking to a former associate I used to work with about a new "[Inversion of Control][1]" (IOC) container I had been playing with. He is a big OOP enthusiast but had not heard of IoC before. He later emailed me that after his research that Inversion of Control was nothing new and that it was formulated a long time ago in the "[Dependency Inversion Principle][2]" (DIP).

(FYI: DIP and IoC's primary purpose is to decouple implementations of classes. With that come many benefits too long to go into in this post. But I highly recommend following the links provided in this article to learn more.)

I have heard this before and I agree that IoC is definitely not something new.

But there are some differences. "[Dependency Inversion Principle][2]" is an

Object Oriented Design **principle** where as "[Inversion of Control][3]" is a

Design **Pattern**. Principles are meant to be followed but provide only the

basic guideline to follow where as Patterns are concrete solutions to common

problems so there alone separates their purpose/intent. Personally I think

that Ioc is at the core of DIP, but they both compliment each other but in

different aspects. (Think chicken before the egg?) The only way you can have a

good, successful _dependency inversion_ of a class is by using one of the IoC

patterns (I, II, or III) or also as my friend suggested to me the alternative

design pattern "[plugin][4]".

Then as my friend asked, what is the hype about IoC containers and when do we

use an IoC contatiner over creating our own Plugin? (Paraphrasing here)

First what is a [plugin][4]? To summarize, it links classes during

configuration _rather than compilation_. The plugin depends heavily on

factories and some conditional logic to decide which implementation to return

to the requesting client. The plugin can be used in many contexts but the

[author][5] originally wrote its primary purpose for unit testing or running

an application in multiple environments. Factories can be evil for reasons

like that they usually implement the singleton, or another problem is that now

you may have avoided tightly coupling two object implementations by using DIP

but the requesting client is still tightly coupled to a factory class to get

it's loosely coupled implementation.

What about [IoC][6]. Using an IoC container assists us in DIP without

recreating the wheel. Though each container use different ways (see below) of

binding implementations dynamically during runtime…none of them use a factory

to that. We can also now choose our preferred method of IoC using open freely

available frameworks. I wont go to company A and have to learn company A's

proprietary IoC framework and then do the same again for company B, company C,

and so on. - Standardization is good.

*Very Quick Reference to how IoC is implemented in frameworks. I use the

dependency injection terms (setter, constructor, interface) over the original

IoC terms (I, II, III). Martin Fowler provides us with an [easier way][3] of

understanding this pattern.

  * Setter

    * This usually requires an external configuration file that will bind

classes together. This depends on properties to provide the implementation to

the class needing them.

    * .Net Implementation:

      * [Spring.Net][7]

  * Constructor

    * A Class that requires supporting classes get these through the

constructor as arguments. The client code will request a specific type of

object from the framework. The framework then will Instantiate an instance of

an object of that type or of a class that implmenets that type. Every class

needed will by linked up dynamically.

    * .Net Implementation

    * [Castle Project][8]

    * [PicoContainer][9]

  * Interface

    * The framework will bind up classes that match particular types of

interfaces. I know this is a weak definition but there are lots of sources

that go deeper into these subjects if you wish to learn [more][3].

    * .Net Implementation

      * [Castle Project][8]

   [1]: http://www.martinfowler.com/articles/injection.html

   [2]: http://www.objectmentor.com/mentoring/OOPrinciples

   [3]: http://www.martinfowler.com/articles/injection.html

   [4]: http://patternshare.org/default.aspx/Home.MF.Plugin

   [5]: http://www.martinfowler.com/

   [6]: http://wiki.apache.org/excalibur/InversionOfControl

   [7]: http://www.springframework.net/

   [8]: http://www.castleproject.org/castle/show/HomePage

   [9]: http://picocontainer.org/

Permalink | Leave a comment  »

IComparable, Custom Objects, and good OOP

over 4 years ago | Matt Deiters: The Agile Developer

Anyone that has worked with me knows that I am anti-datasets and pro-creating
custom business object/entities. Microsoft has spent some time making their
controls, like the _DataGrid_, work very cohesively with the _System.Data_
classes (primarily _DataTables_ and _DataSets_). To take advantage of the same
functionality with my custom collections I have to implement the
_IBindingList_. The _IBindingList_ is the interface that is at the root of the
_DataTable_ and is what the _DataGrid_ and other controls use to effectively
bind data to the UI.

**Sorting**

Along with having a collection of my custom objects, I need a way to sort the
list. I had created a class called _ObjectComparer_ and it implements the
interface _IComparer._ This is the interface the sort method on the
_ArrayList_ accepts as an argument. I created this along time ago but recently
a co-worker brought to my attention another fellow Milwaukee developer that
[implemented something very similar ][1] on his blog.

He did a decent job except that in his example the comparer only compares on
properties of objects that are of type _int, double, string, and DateTime_ and
has a method to handle each specific type. The advantage of using the comparer
I provide below is that it doesn't care or need to know about the type of the
property on the object you are comparing against, as long as the type
implements _ICompareable_ interface (The _IComparer_ counterpart). Many types
in the .Net framework already implement this interface (including the _int,
double, string, and DateTime_). Plus if you create a custom class, you can
also extend your class with it's own implementation of how to compare itself
against another object of the same type by implementing the _IComparable_
interface. This really demonstrates the power of interfaces because my
_ObjectComparer_ code never needs to change to handle any specific types
because it only deals with the _IComparable_ interface. Where as with the
other developers sample, everytime you wish to be able to compare on another
type, you have to edit his object comparer. Below is my implementation of a
_ObjectComparer._

**MultiKey Comparison Sorting**

I first saw the other developer's custom object IComparer last week when he
[posted ][2] on how he changed his original implementation to now handle
multiple properties to do the comparisons on to sort. My co-worker suggested
that we may want to implement the same functionality. When I saw what the
author had changed the inner workings of his class by modifying it, alarms
went off. This is a big violation of the [open-closed ][3]object oriented
principle. Basically the open-closed principle means the "Objects should be
open for extension and closed to modification." By extension, the principle
means either by preferably using inheritance or composition. Modification
means going into "already working" classes and changing implementation -
potentially making your class unstable. So instead of modifying my
_ObjectComparer_ I decided to create a new class called the
_MultiKeyObjectComparer_ which internally (composition) uses several instances
of the _ObjectComparer_ and its already stable working functionality. In the
defense of the original author, some may argue that his API (public interface)
would be friendlier in the sense that you could continue to use his object
comparer and another developer would see the new functionality using
intellisense because of the additional constructors and methods, where as with
my design the developer would have to be aware of the new
_MultiKeyObjectComparer_ that I created to benefit from it.

(On a side point, after implementing this, the next morning another altogether
separate co-worker requested the functionality for a UI he was doing,
completely unaware that I had already been looking into this…weird
coincidence).

[1]: http://www.damonpayne.com/BlogFull.aspx?Guid=b8405b9d-8f6d-
4d53-8e83-8764b2027fb6

[2]: http://www.damonpayne.com/Blog.aspx#0e692666-10f9-4ecc-87df-
bc14ed5784d1

[3]: http://c2.com/cgi/wiki?OpenClosedPrinciple

Permalink | Leave a comment  »

MSDN AOP Article Published

over 4 years ago | Matt Deiters: The Agile Developer

My article on aspect oriented programming has been published on MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/AOPArticle.asp).

Permalink | Leave a comment  »

Hair Raising!!!

over 4 years ago | Karthik: Chain of Thoughts