When not to use IoC and DI?

Question

I see lots of articles saying how great IoC and DI are and none about why it isn't so great because it can make code more complex. I see also that IoC shouldn't be in the core part of your code but more for libraries and plug-ins. Articles usually a small reference to how the two patterns can make code more complicated but not much on the details of that. That is my question - where specifically should you not use these patterns?

This is a nice thread: http://stackoverflow.com/questions/3058/what-is-inversion-of-control. If you look further down, there is a post about the spell checker and another post about how IoC is probably not a good use there if it is only one spell checker. As a general guideline, should IoC not be used of I ever have only one concrete class for the interface? Meaning, I have IMyClass. And then have just the concrete MyClassA that implements IMyClass. Why would I want IoC there?

If I had MyClassA, MyClassB and MyClassC, that each implement IMyClass, those are probably good candidates for IoC correct?

From the same thread, does anyone know what this post means:

• Inversion of Control = Marriage
• IOC Container = Wife

Answer 1

From the Castle Project:

Why would I not use it?

You should not use an Inversion of Control container if you are not familiar with the concepts and if you do not realize the problems they try to solve.

Also, depending on the size and complexity of the project, an IoC container might be overkill. Prefer to use it on medium to large projects.

Answer 2

About your question about having only one interface implementation. When you use IoC, it is still useful to use an interface. It will be much easier to create real unit tests (that doesn't depend on the interface implementation to be working correctly) using mocks for these interfaces. The core of using IoC is making code easier to test. So, don't use IoC if you don't want to test, or already have a better plan on testing without it.

IMHO, DI and IoC increase in complexity comes is paid by having an easier to test and less coupled code. It's easier to isolate the problems and to make future changes. You can control its behavior better too.

I can see when not to use an IoC container (as it results in configuration overhead). This would happen on small projects, where you can do it manually, instead of using a container. But I can't see much loss from using DI, unless you're not planning to test your code...

Answer 3

The complaints about IoC are easy to understand: IoC turns something simple into something complicated. Let's say you wanted to do something to each element of a list (in pseudocode):

for each i in list:
    do_something(i)

IoC, essentially, is moving the responsibility for loop iteration to someone else. Thus, we end up with something more like this:

ioc = new IocContainer()
ioc.register_callback(do_something)
ioc.go()

Notice that even in this simple form, the code is longer than the original... and that's not counting the implementation of IocContainer.

Then, in its fanciest form, the IocContainer can get initialized statically or by a static Main() function or somewhere else hidden away, and the register_callback() functions get called automatically based on some other code that iterates through an XML file that lists all your do_something() functions and (sometimes) even the contents of the lists to iterate through.

Yay, the XML file has made your software more configurable! Right? You can change which somethings are done to your list just by changing a simple text file!

Except, ironically, your source code is now longer and harder to understand, it depends on all sorts of new, possibly buggy, libraries (including the IocContainer and an XML parser), and you've actually made it harder to maintain: XML code is harder to understand and edit than the original simple source code loop (no matter what language the loop is written in). You also have less control over exactly how you want to do the iterating (sorted or unsorted? depth-first or breadth-first?) since IocContainer is taking that responsibility away from you.

For things like plugins, it can make sense to use IoC, since it's logical for the main application to be in control of the execution process, and to just ask the plugin for help here and there. This is called "providing hooks" and has been around much longer than the IoC terminology.

For things like unit tests (which is where I've usually seen it thrown around), IoC usually turns out to be unhelpful, because your tests need to be able to simulate a wide variety of odd situations, and IoC just constantly gets in the way of this.

The fundamental assumption of IoC is that loading data and looping through is somehow difficult and needs to be abtracted away; this assumption just isn't true, because it was never more than a couple of lines anyway (or you could move it to a separate function), and even if it did save code, it reduces your flexibility.

Answer 4

Using an IoC container or not isn't a decision to make at the level of individual classes - in any project you'll have types that are and aren't created by the container.

The complexity tradeoff is this:

• For a small number of components, an IoC container does add some overhead
• As the number of components in an application increases:
  • Without an IoC container, adding new components or refactoring tends to get increasingly difficult
  • With an IoC container, adding new components or refactoring stays the same: you only ever need to worry about the immediate dependencies of the component you're adding or changing.

If you've ever experienced the phenomenon of even a well-designed and maintained codebase becoming unmanageable with size, you've experienced the problem that IoC containers solve.

Answer 5

IoC/DI are not technologies, they are paradigms. Your question is akin to asking "When should I not use object-oriented programming?" It is a decision that is bigger than the individual units of your codebase.

To answer your specific question, if you have few enough classes where you can reasonably construct object graphs by hand, and you are not repeating the same object graph instantiations multiple times, you might not need an IoC container.

Answer 6

I guess I'd say the simple answer only use IoC on objects you wish to unit test.

If this seems flippant I'm sorry, it's out of frustration at code written with literally NO consideration given to unit testing. I don't really understand why there is added complexity--if I needed to know the actual object type for sure I can always print out the class at runtime.

Answer 7

Inversion of Control = Marriage

IOC Container = Wife

Marriage is the definition of a known pattern - Wife is the implementation of that pattern ;-)

Bernard.