I've recently been bitten by code that uses Inversion of Control when it's not appropriate. Lately, I'm of the opinion that IoC is among the patterns that have the worst effect when misapplied. This is because it tends to create a coupling of classes that can cause a lot of shotgun surgery if you run into a circumstance that's a little different from what you had originally intended.
So, I'd like to get a clearer picture of when IoC should and shouldn't be used. Any advice?
If there's actually good flexibility/re-use value from a framework design you hook into with callbacks, then that is OK.
But when it's a framework providing flexibility/re-use that you're never in fact likely to make use of (YAGNI), that's a case where the framework approach and associated IoC are over-architected and misguided.
Edited to add: And re: the shotgun effect of changes... verly likely when trying to turn a solution into a general framework before there's even an understanding of the best solution and what might actually be realistically reusable. Somewhere I saw someone recommend a "rule of three's" for this: Don't try to architect a general solution for something unless you've already solved it a couple of times before. Worth considering.
Firstly, I would like to recommend this article from none other than Mr Martin Fowler LINK. IMO unless you are very sure that the pattern is necessary do not implement it. You should use a good iterative process and incorporate the pattern if required. Do not force it. I would first design the system on the idea of design by interface or contract to understand the dependencies. If you see it getting too large and not easy to maintain, you can make a call.
One rule of thumb I find useful is to not consider IoC until you start thinking about Singletons. Once you're on that path then IoC might be useful (and most times preferable to a Singleton). Before that point I like to follow the YAGNI principle. Using boring old constructor injection or similar works most of the time. It will keep your implementation easier to understand, and your tests easy to write and understand.
Using boring old constructor injection or similar works most of the time.
Yes it does. Personally, I'd call that IoC. :) The question in my mind is, when is it appropriate to introduce an IoC container or framework?
IoC of any sort decouples your classes; the immediate benefit (as Mr. Hodgson mentions) is testability. When used with a mocking framework, IoC makes it easy to test your classes in isolation. I'd also agree with him in that Singletons are evil - IoC/DI containers give you all the flexibility of Singletons without some of the drawbacks (particularly if the injected classes are immutable).
I'd probably go with Anon's rule of three's - but as soon as you have three classes that depend on each other, consider an IoC container.