Advertisements
Posted by: jsonmez | November 23, 2010

Back to Basics: Understanding IoC

In my last back to basics post, we talked about dependency inversion and how it is the underlying principle that Inversion of Control or IoC is based upon.

We also talked a little about IoC and the three main forms of control that can be inverted; interface, flow, and creation.

In this post I want to dive a little deeper into IoC as it relates to interfaces and creation, we’ll ignore flow inversion for now, because it is often used in a way that is completely unrelated to the other two.

We’ll focus more on creation since we already covered interface inversion a bit and creation inversion is the “hot thing” right now.

Interface inversion

Why would we want to invert interfaces?

We covered much of the reasoning in my post on dependency inversion, but there are some important points that specifically relate to interfaces in programming that I would like to address here.

First we must understand what non-inverted interfaces are.

Let’s take an example.  Suppose I have a Kangaroo class that has several methods, among them is Punch. Normally, Kangaroo defines the interface that has to be used if you want to use the Kangaroo class.

By default the constructor for the class and the method signatures all make up an interface that the user of the Kangaroo class must adhere to in order to use the Kangaroo class.  The module that contains the Kangaroo class usually also would include the interfaces if one is defined.  In this case the interface would be something like IKangaroo.

Non-inverted

Why do I say this is normal and not inverted?  Because it makes sense that a class would define what it does and how to use it, not some other entity.

An inversion would be if some other class or module told Kangaroo what its interface needed to be.  Kangaroo would stop being an independent definer of a service it has to offer and instead become a provider of a service someone else wants.

From our narrow viewpoint of the Kangaroo class we don’t know what kind of interface to provide, so we have to assume it is something like IKangaroo.  The way we look at the Kangaroo class can completely change though, if we consider the BoxingMatch class.

If we create a BoxingMatch class, we really want that class to define the interface that all boxers must adhere to.  We don’t want to have to have the BoxingMatch class know how to make multiple classes with different interfaces box.  So within the module that the BoxingMatch class is defined, we define an interface called IBoxer.  Within the BoxingMatch class itself we use IBoxer instead of specific classes that we want to use in our boxing match.

Now we have given Kangaroo a suitable interface to implement.  IKangaroo hardly makes sense, but IBoxer gives our Kangaroo a purpose.  Our little Kangaroo class is providing a service.  He can box!

Inverted

In this example you can see that we have inverted the control of the interface.  Instead of letting the provider of the interface define that interface, we have made the user of the interface define it.

The value we gained here is that we have given control to the higher level module and reduced the complexity of its logic by preventing it from having to deal with every different interface defined by classes that can box.

Up next creation inversion

I’m going to end this post here, since creation inversion is going to be a longer topic, and I am on vacation right now.

In my next post we’ll cover creation inversion and talk about how it relates to Dependency Injection or DI.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.
Advertisements

Responses

  1. “In this post … We’ll focus more on creation since we already covered interface inversion a bit and creation inversion is the “hot thing” right now.”
    Hmm?

  2. […] Back to Basics: Understanding IoC – John Sonmez continues his back to basics look at Inversion of Control and Dependency Injection / Inversion, and in this part focuses in the Inversion Of Control side with a look at Interface Inversion. […]

  3. Nice post, I like the way that you brought in IBoxer rather than just IKangaroo, etc. Ties in nicely with your other post regarding interfaces and goes a little further than most examples that do keep the 1 to 1 method mapping of interface to implementing class.

  4. […] my last back to basics post we talked about what inversion of control (IoC) is in regards to inverting control of […]

  5. […] Blog : Back to Basics: Understanding IoC […]

  6. I am struggling with one problem: I’ve created layered architecture – DLL, GUI. In DLL, I’ve use NHibernate as ORM. Now, if I want to use my DLL objects from GUI, I have to reference both DLL and NHibernate libraries. It works, but I’m asking myself if this is ok? I’ve thought that I will only have to reference DLL in my GUI, not Nhibernate as well. How do you solve this kind of problems? Is it normal that you have ORM dependencies in other layers as well?

    • The only way to solve this is to use another layer to map your objects across, basically create DTOs or data transfer objects.
      So lets say your ORM code has a Person class that represents the person table in your database. You can create another Person class in your middle layer. Then you essentially create a new version of that Person using the one from the ORM. It is a bit like passing the baton in a relay race.

      Now some people will say this is just a pollution of extra objects, and I tend to agree with them. Unless you have a good reason to introduce a whole new layer and extra complexity, I would stick with what you have, but it is up to you.

  7. Thanks for answer. With NHibernate I don’t have a problem with mapping objects – those are in DLL and it’s enough if I reference DLL. But, NHibernate needs session object – and I cannot create one without referencing NHibernate class library.
    I’ve read majority of your blog posts. Good stuff. Keep on doin’ good job.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: