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.
Inversion of Conmtrol vs Dependency Injection
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.