The PEAK Developers' Center   Diff for "InversionOfControl" UserPreferences
 
HelpContents Search Diffs Info Edit Subscribe XML Print View
Ignore changes in the amount of whitespace

Differences between version dated 2003-10-29 12:16:53 and 2007-03-26 18:36:06 (spanning 9 versions)

Deletions are marked like this.
Additions are marked like this.

Inversion of Control is a pattern for reducing coupling between classes/components and the components they use. Instead of a component directly instantiating its dependencies, it defines them declaratively, and relies on its clients or environment to provide them. This makes it easier to reuse the component with different collaborators.
#pragma section-numbers off
 
For a simple example of using ```peak.binding``` to do this, see PeakDatabaseApplications. (ComposingHierarchies provides a more complex example.) For more info on the Inversion of Control pattern (also known as the Dependency Inversion Principle), see:
'''Inversion of Control''' (aka '''IOC''') is about breaking dependence between objects by placing interfaces between them. In particular, Inversion of Control focuses on breaking the dependence of ''high-level'' objects on their ''low-level'' modules.
 
 * [http://www.objectmentor.com/resources/articles/dip.pdf A seminal article on the Dependency Inversion Principle and its significance]
Even more specificly, we talk here about '''dependency injection''': When an object is created, it is given its dependencies, rather than making them on its own. (Another approach is ServiceDiscovery, not described here.)
 
 * [http://www.picocontainer.org/ioc.html PicoContainer page on IoC] (!PicoContainer is a Java implementation of a small part of what ```peak.binding``` does)
Traditionally, an object creates the objects it needs. Something like:
 
{{{
#!python
class Eggs:
 
    def __init__(self):
        self.my_spam = Spam("foo", "bar") # Eggs is creating its own Spam.
}}}
 
However, we can invert the control. Instead of creating the object, and perhaps demanding that the environment conform to its choices, we ''invert control.'' The environment will fetch your dependencies for you.
 
{{{
#!python
class Eggs:
    def __init__(self):
        self.my_spam = None
 
    def set_spam(self, spam):
        self.my_spam = spam
}}}
 
(This variant of [http://martinfowler.com/articles/injection.html#SetterInjectionWithSpring dependency injection] is called [http://martinfowler.com/articles/injection.html#SetterInjectionWithSpring setter injection.])
 
  ''Ideally, we'd like a PEAK example here.''
 
What did we gain by this? There is more control in the environment now. With the environment taking care of more details, there is less a chance that the object will include a hard-coded decision that the environment has to work around. The flip side is that the environment is now tasked with taking care of more details. But when you are working to create complex reusable components, this tends to be the direction of things: The fewer unnecessary decisions that the component makes, the more likely the component can be reused within another environment.
 
For a simple example of using ```peak.binding``` to do this, see PeakDatabaseApplications. ComposingHierarchies provides a more complex example.
 
For more about "Inversion of Control" aka "Dependency Inversion Principle," see:
 
 * [http://www.objectmentor.com/resources/articles/dip.pdf The Dependency Inversion Principle] - Explains Inversion of Control in plain language.
 * [http://www.picocontainer.org/Inversion+of+Control PicoContainer:Inversion of Control] - note: !PicoContainer is a Java implementation of part of what ```peak.binding``` does
 * [http://www.picocontainer.org/Differentiators PicoContainer:Differentiators] - Critiques several Java frameworks, patterns, from perspective of IoC.
 * [http://martinfowler.com/articles/injection.html Inversion of Control Containers and the Dependency Injection pattern] - Discussion of the IoC pattern, compares to the Service Locator alternative. Martin Fowler.
 * [http://www.theserverside.com/discussions/thread.jsp?thread_id=23358 Martin Fowler renames IoC: Dependency Injection] - Discussion around Martin Fowler's article.
 
== Commentary ==
 
"Inversion of control" was probably a bad name choice.
 
First, it's based on a rejection of a prior tradition. As the older tradition becomes less known, people aren't so sure of what's being inverted against. That is, the phrase is mortal.
 
Second, the relationship between ''high-level'' modules and ''low-level'' modules isn't necessarily inverted. Rather, there is now an "environment out there," and "me out here." Perhaps it would be better to think in terms of "inside, outside," or even "near, far," rather than "high, low." When dependencies are all held internally, there is a clear high-low relationship: Things that are held are low, things that hold you are high. But when all dependencies are external, there is no such clear high-low relationship. That thing that you thought was below you may now instead just be a facet of the thing that's "above" you. And vice versa. Or maybe not. The point is, you don't know.
 
ExternalControl may have been a better name for the general principle behind "Inversion of Control."
 
-- LionKimbro [[DateTime(2005-04-17T05:04:09)]]
{{{

PythonPowered
ShowText of this page
EditText of this page
FindPage by browsing, title search , text search or an index
Or try one of these actions: AttachFile, DeletePage, LikePages, LocalSiteMap, SpellCheck