Here is a question from Joseph:
This description sound right to you?
Stefano Mazzocchi:
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 behaviour for subclassed 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 hte fact that IoC is not what Avalon does (so not a design pattern), but a much more general principle that Avalon simply used.
Here is my answer:

I would say that IOC and Dependency Injection are not the same thing. Both are design patterns. Inversion of Control is the more abstract notion. Dependency injection is more specific.
They overlap a lot – hence the confusion above. I would say this – “Dependency Injection is only one pattern which makes use of the IOC pattern”.
The IOC pattern simply says that objects are enabled for something else to configure/control them. This “something else” might be a framework or it might be another object – it is not necessarily a framework that is doing the configuring. In the most abstract sense a network of cooperating objects could mutually configure each other and all will be happy.
A perfect example of IOC that would *not* be dependency injection would be a piece of Java code which wanted to display a calendar widget within a GUI. The code creates a calendar widget object, then calls methods in the calendar widget instance and sets a few parameters like background color. Then the Panel widget is called (another example of IOC) and told to add the calendar widget instance to the panel in the upper left hand corner. The panel and calendar widgets are allowing themselves to be configured via IOC – but the calling code (in control) is just another piece of Java code and not particularly a “framework”.
Martin Fowler’s coining of the terms IOC 1,2,3 really were talking about the interaction between a framework and a component working within the framework. Perhaps a better way to title Martin’s work would be “Three different ways that frameworks use the IOC pattern”. Dependency Injection is best described as “What Spring Does”. Spring (a framework) feeds an object (a component) configuration values and classes (implementations) for requested APIs (Interfaces) using the IOC pattern.
Another way to look at this from a Java perspective – the notion of setters is the most basic form of IOC. Martin’s work took the setter pattern and suggested that the best way for a component to find its dependencies was through the setter pattern (i.e. IOC is the best way for a component to get its dependencies from a framework).
The Sakai framework component approach are based on this notion of Dependency injection. Sakai uses classic IOC throughout tools, presentation layer, etc etc.
There are places in Sakai where IOC/Dependency Injection is not practical or quite inconvienent and so different patterns are used. That is a different fun debate when IOC purists meet the real world.