Joel against Inversion of Control

1
1 Like
2

I’m with you, Vadim. IoC containers take a simple, elegant, and
useful concept, and make it something you have to study for two days
with a 200-page manual.

Hero.

3 
            How this: ninject.codeplex.com/Wiki/… is considered rocket science is beyond me.
            – 
                Sam Saffron
            Sep 19 '09 at 1:58

His link:

class WarriorModule : StandardModule {
public override Load() {
Bind().To();
Bind().ToSelf();
}
}

Uh. What?

4

This post also proves programmers aren’t nice people.

5

I think the term is “10x programmer.”

1 Like
6

Here’s Martin Fowler’s article on it. I have to say that I don’t really understand why the first example (Pico), with constructor injection, requires an IoC container at all, or why using constructors even adds a box to the diagram. Seems like you just pass the finder you want in your constructor and you’re done. Anyway, the Spring example makes me nauseous. Finally, despite this being kind of a pro-IoC article that launched a lot of efforts/adoption, he acknowledges this:

“Inversion of control is a common feature of frameworks, but
it’s something that comes at a price. It tends to be hard to
understand and leads to problems when you are trying to debug. So on
the whole I prefer to avoid it unless I need it.”

The only explanation I have for its popularity is that people in grunt roles of pumping out tons of Unit Tests find it so tedious and grueling they are willing to compromise the maintainability of the entire application just to make that task somewhat easier.

1 Like
7

I’m reading all of the comments on Joel’s answer. I COMPLETELY forgot about all of the runtime errors that get introduced when you mess up ninject.