April 2, 2008

...Learn TDD with Codemanship

Inversion of Control - Are We Sweeping Dependencies Under the Carpet?

Maybe I'm being incredibly naive here, but isn't there a danger that people will abuse Inversion of Control as just a way to hide dependencies from the compiler?

The dependency doesn't go away. If I edit my IoC configuration files, it can break my code. And that means I have to treat those files and their contents as production code. When they change, we need to restest every part of the system that depends on them. That, to my clouded mind, sounds like a dependency - except that it's much, much harder to spot.

I've worked with teams who have had a field day with IoC frameworks like Spring and Castle, and I have finally come to the conclusion that you should write your dependencies in code where the compiler - and other code analysis tools - can see them.

Manage the dependencies in your code. Don't just sweep them under the carpet and pretend they don't exist. They can still hurt you.

Like Singletons, IoC is not necessarily - in of itself - a bad thing. But they both seem to be commonly abused, leading to code that is crappier than the problem they're trying to solve.




Posted 10 years, 3 months ago on April 2, 2008