On Inversion of Control
January 22nd, 2004
I introduced the concept of IoC in the Avalon community in 1998 and this later influenced all the other IoC-oriented containers. Some believed that I was the one to come up with the concept but this is not true, the first reference I ever found was on Michael Mattson’s thesis on “Object Oriented Frameworks: a survey on methodological issues” published in 1996 that on page 96, in the conclusions, reads:
An object-oriented framework is a (generative) architecture designed for maximum reuse, represented as a collective set of abstract and concrete classes; encapsulated potential behavior for sub-classed specializations.
The major difference between an object-oriented framework and a class library is that the framework calls the application code. Normally the application code calls the class library. This inversion of control is sometimes named the Hollywood principle: “Do not call us, we call You”.
Mattson’s doesn’t reference the source of that principle so I can’t track it back any further.
Now it seems that IoC is receiving attention from the design pattern intelligentia:Martin Fowler renames it Dependency Injection, and, in my opinion, misses the point: IoC is about enforcing isolation, not about injecting dependencies. The need to inject dependencies is an effect of the need to increase isolation in order to improve reuse, it is not a primary cause of the pattern.
Moreover, I think Michael Mattson is right: IoC is not even a design pattern, but a general principle that separates an API from a framework, based on who is in control. Dependency Injection misses that entirely and misleads the reader to believe that this is just another way of composing objects. I don’t blame Martin Fowler for that, I blame those who came up with IoC type 1,2,3 and missed the point entirely about the fact that IoC is not what Avalon does (so not a design pattern), but a much more general principle that Avalon simply used.