Talk:Inversion of control/Archive 1

Archive 1

Archive 2

Regarding the Terms and Definitions section

I think the changes made by Julian Morrison were absolutely justified. This *is* ridiculous. It sure is a carefully worded explanation that took some time to work out, but imho it's quite out of place in this article. Maybe a common terms and definitions in object oriented programming page should be created that can be shared by all such articles. — Cygon 15:24, 21 February 2006 (UTC)

I agree. I suppose one challenge is knowing how much background explanation is appropriate before jumping into the meat of the subject matter. I would argue that in order to approach answering this, a certain audience should be presumed (developers who understand OO principals), with heavy linking to other parts of Wikipedia for those who might be weak on the background necessary to understand IoC, rather than verbose inline exposition. The current page seems to attempt to define and develop a lot of elementary concepts that could theoretically appear at the beginning of many design pattern articles, and IMHO, factoring them out would allow the article to get to the point. Julian Morrison's version communicated at a level that I was comfortable with, while the background in the current one (while carefully crafted) seems tedious to me. Mike Fikes 21:50, 21 February 2006 (UTC)

Although I disagree, feel free to do what you think is best. I have tried to describe dependency inversion to non-programmers. I know dependency inversion from Robert Cecil Martin's Books and the Dependency Inversion principle as he describes it, is a central part in OO software design as it helps to reduce coupling. Maybe IoC in Java is too different compared to DI. I know C++ quite well but not Java equally well. I had actually some hard thinking to describe it as I did here. So maybe I have some too strong ownership feelings here. It just hurts a bit if you work hard and someone throws your work out under the term "ridiculous". But of course that doesn't matter. I must say, I don't know how much knowledge can be presumed for the average reader here. Of course the intro I did is ridiculous for every OO programmer. I even think that whole article is ridiculous for an OO programmer. But then you might even throw out articles like class (computer science) — or which OO programmer needs an article about class? I don't know what's the policy on Wikipedia on this. So I might have gone over board. I personnally find it helpful that I can read an article on human medicine here and understand that without being a brain surgeon or taking introductory courses to read medicine articles on Wikipedia. I assume a lot of contributers here are computer geeks. But this is not an encyclopedia for computer geeks only. Just some thoughts. As already said, feel free to throw out. I will not revert again. --Adrian Buehlmann 22:29, 21 February 2006 (UTC)

I agree with Mike Fikes and Cygon, on the basis that if authors write articles on specific topics that include lengthy background information to accommodate readers with little domain knowledge related to the topic, then Wikipedia's content degrades in two ways:

1. There is a lot of redundant content generated in these background sections. If every article on a sub-concept of OOP has a section describing OOP basics, then we wind up with dozens of different OOP introductory descriptions.
2. It clutters the information on the topic for users already familiar with the domain.

As Mike Fikes says, link heavily if background info is necessary to understand a topic. I think that's part of the inherent power of Wikipedia: "information reuse," if you will. We programmers prefer to say things only once, if at all possible, and Wikipedia makes that very possible. --Scottymo 18:01, 22 February 2006 (UTC)

I agree with that. The problem is I didn't find enough articles with enough info to refer to in order to explain dependency inversion (seems also to be a misconception of the terms, see talk with Paul below on this page). The articles I found were just too unspecific or not up to the point of info that I felt was needed to understand dependency inversion. That's all. As I already said. Just go on and delete. I will not revert. --Adrian Buehlmann 19:00, 22 February 2006 (UTC)

Pretty clear to me

Hi, anonymous lurker here. I don't understand why this should be so complicated (I'll keep my conspiracy theories to myself). Although the following is my interpretation and therefore "orginal research" or whatever, you can use my explanation to understand the source materials and hopefully fix this awful article.

Let's start with "A has-a B". This is your basic construct and useful by default. However, let's say you want to break the dependency (reduce coupling, whatever). Like in the current version of the article, you introduce C (an interface in Java) which describes (i.e. is a super of) B. Now you have "B is-a C, and A has-some-kind-of C.". You've broken the dependency, but nothing so far uniquely characterizes DI. This is just basic use of polymorphism! Note that you now have a new problem: how to decide how A will select a specific instance of C to depend on.

In the naive method, A has one simple line of code somewhere that states B is the specific C that it will use. So now we have "B is-a C, and A has-some-kind-of C, which for the time being is B." Although you've recoupled A to B, it's a very tiny dependency. You are still getting most of the benefits of polymorphism, because it's (theoretically) simple to change that one line of code to select a different kind-of C (D for instance) and recompile. You only have to change one line in A.

Dependency Injection, however, is a way to solve the selection problem, retain full decoupling, and get a gold star. The innovation of recent years was NOT the discovery of this very simple technique, but to popularize a name for it so that it could be identified, communicated, and taught effectively. Unfortunately a lot of people have made it a lot more complicated than it is.

Dependency Injection requires that A provides an external mechanism to select ("inject") the specific kind-of C that it will use. That's all there is! This mechanism is often as simple as a single parameter to the constructor. Done. Nothing else needed. "B is-a C. A has-some-kind-of C, tell me which one you want me to use."

What you have done is you have shifted the responsibility for solving the dependency-selection problem from A to the external entity. A and B remain blissfully unaware of each other. Using A now requires some assembly, but you get the freedom to decide what to plug in, and best of all, you can make this choice at run-time.

Besides the naive method and DI, there is a third method sometimes called "Service Locator". It was often used before DI became popular. It doesn't fully break dependencies like DI, but it does minimize and concentrates them. However, it's really ugly (often implemented with global components) and complicated. DI, in comparison, is almost too simple to understand ("i don't get what's the big deal...") and yet it cleanly and fully solves the problem.

Regarding terminology, I'll admit I don't care too much for it. I'll leave that debate to the politicians. The above, however, is the core concept. I put this in the IoC article because DI redirects here.

Thanks for that description! I got a distinctive feeling that the main article went way out of its way to make it more complicated than it really is, but your version was concise and to the point. Turns out it's just a basic and obvious way of handling dependencies, but with a fancy name. In my opinion, your description should be used as the main description of the concept, along with a note along the lines of "IOC covers dependency injection in this manner, as well as other techniques that follow the same basic pattern (e.g. callbacks)". Khim1 15:34, 29 August 2007 (UTC)

AOP and strategy pattern

This article has serious flaws, the concept of IoC is limited to dependency injection. AOP and the strategy pattern are also forms of IoC that should be discussed as well.

This anonymous remark was made on 24 August 2005 by 148.177.129.212 (I moved it to this new section). In the mean time, I have done a major rewrite. Please review the article again. However, "AOP" and "strategy pattern" are not mentioned (as of now). — Adrian | Talk 15:17, 16 November 2005 (UTC)

Concerns by Paul Lee

IoC is a relatively new concept that has been made popular by the Spring Framework. I wouldn't call it an OO design principle. In addition the description of IoC in the article is the same as the principle of programming to an interface instead of an implementation. I don't think it's a proper description of IoC. The introductory section on OO is superfluous and confusing. It takes up the majority of the article. A more balanced article should also discuss the tradeoffs as well as the merits of IoC. - Paul Lee

Hi Paul. The "Dependency Inversion Principle" is mentioned in (Martin 2002:127) and is actually older than the Spring Framework I suppose. There is also a description by Robert Cecil Martin of that pattern in his 1995 book (Designing Object Oriented C++ Applications), but I think there he did not coin the term DIP yet (though I'm not shure). I added the intro because there was a complaint on an older revision that it was not understandable. I thought that Wikipedia cannot assume that its readers are OO programmers, thus I tried to only add what's absolutely needed to understand DIP/IoC. I looked into other articles but didn't find material that would fit that closely, so I added it here. It is correct that the intro uses a lot of space. But if you know what's in the intro, the rest is easy to understand. It drives directly to the point. Adrian Buehlmann 00:26, 7 January 2006 (UTC)

Adrian, I still think the intro text can be made more concise. I also think your intepretation of IoC is not correct. From what I've read, IoC is simply a way to define the implementation of a class at runtime instead of compile time. This is the "inversion" or "injection" aspect. Instead of using the built-in syntax of the code to control instantiation, such as the "new" keyword in Java, you use reflection, which defines the concrete implementation using uncompiled text, such as "MyClass.class". The main motivation seems to be that you can now define your class or interface implementations at runtime instead of compile time. Of course, the tradeoff is that you have bypassed the built-in syntax checking of your compiler. Again, your interpretation is simply describing the use of interfaces as opposed to an explicit implementation. - Paul Lee

Adrian, I think I see where my confusion lies. It seems that "Dependency Inversion" is not the same concept as "Inverison of Control" and "Dependency Injection". "Dependency Inversion" is not referenced in any of the articles for "Inversion of Control" or "Dependency Injection" you reference and seem to be describing different concepts. However "Dependency Injection" is clearly mentioned as a revised name for "Inversion of Control". I think you should no longer be associating "Dependency Inverison" with "Inverison of Control" and "Dependency Injection". "Dependency Inversion" seems more related to the principle of "Program to an interface, not an implementation" which is noted in several OO design books such as the Gang of 4 Patterns book (p.18) - Paul Lee

(Unindenting. I assume this was you Paul. Please consider creating a login. Your are very welcome!). Hmmm, the problem probably started here. An there was that "In need of an expert box" which drove me to stuff in my verbose OO essay. Maybe I just over-egged the pudding :-). Would it be good to split off Dependency Inversion into a separate article as there might be two different concepts (IoC and DI)? (Blatant attempt to save my essay :-). --Adrian Buehlmann 09:01, 22 February 2006 (UTC)

Sorry I didn't sign. I may create a login if I start contributing, but I actually came here to just learn more about the topic and it didn't seem to be consistent with my other readings. I would simply rename the article Dependency Inversion and remove the references to Dependency Injection and Inversion of Control. Isn't there a link to OO design that you can use instead of the intro text? - Paul Lee

Comments by Hamilton Verissimo

"IOC is also known as the Dependency Inversion Principle (Martin 2002:127)"

This is totally wrong. I've been involved with IoC since 2002 in the Apache Avalon and Excalibur project. More recently I've founded the Castle Project. Quoting Steffano post:

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 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.

Dependency injection is, as usual, a new name that Mr Fowler come for everything. It misleads you to think that IoC is all about injecting dependencies while in fact the concept is broader than that (as someone also pointed out in this discussion). I urge that the page be reviewed as soon as possible. — Preceding unsigned comment added by Hammett2 (talk • contribs) 17:39, 16 August 2006 (UTC)

Resulting dependencies

Would interface I really have no dependencies? What about dependencies carried by the parameters of the methods moved from Y to I?

An interface has no associated implementation. As such it does nothing with the parameters. Using a paramater only by its name and type without actually calling anything from the respective classes does not imply a dependency in the sense of code module dependency (it is only a name dependency). If you take for example C++ there is often a misconception on this as people frequently include unneded headers into headers of interface classes just because a class appears in the signature (the list of parameters) of a member function of the interface class. The definition of such classes is not needed in interface I. Forward declarations like class P; (for a paramater class) in the header file for I are sufficient. --Adrian Buehlmann 09:12, 22 February 2006 (UTC)

In Java, it is common practice to have interfaces depend only on other interfaces because the mere use as a method argument requires the presence of the class for compilation. --Tiago Silveira 14:46, 15 August 2006 (UTC)

Regarding IOC Acronym

I believe I've only seen this acronym as IoC elsewhere, but on this article, it is IOC. I know this is a little pedantic, but IOC looks strange to me. Should we change the article to use IoC, or have people seen IOC in substantial use? --Mike Fikes 01:28, 26 February 2006 (UTC)

I've also only seen IOC here, IoC everywhere else. --Tiago Silveira 14:43, 15 August 2006 (UTC)

I am also more familiar with IoC. In fact, a search for "IOC" on the wikipedia took me to International Olympic Committee! --Bimalesh 05:30, 7 December 2006 (UTC)

IoC and Frameworks

Do "IoC Containers" such as the Spring Framework exemplify IoC? - I would say "yes"; Do they define IoC? - I would say "no". IoC is a principle that is employed by frameworks in which control over the execution of software is "inverted", i.e., a (framework) library makes calls into user code rather than the other way around - another name for IoC is the "Hollywood Principle" (Don't call us; we'll call you!). The Microsoft Foundation Classes (MFC) and the Java Foundation Classes (JFC) are examples of the IoC principle in action (in the domain of graphical user interfaces) - their "event handlers" are one of the hallmarks of the IoC principle. Doug Schmidt discusses the IoC principle in the context of more general Application Frameworks in a 1997 paper here. So why then do I say that containers such as the Spring Framework exemplify IoC? - one hint is in the name "Spring Framework" ;-) ... it may also help things here to postulate just what type of framework the Spring Framework is at its core - a dependency-injection framework. Stated another way, the Spring Framework employs the IoC principle as a mechanism for implementing the Dependency Injection principle. Viewed a third way, the Dependency Injection principle, as exemplified by the Spring Framework, is a specific application of the IoC principle. Thus, "IoC" and "DIP" are not truly interchangeable phrases.

Does any of this make any difference? Probably not - it seems that treating "IoC" and "DIP" as synonyms is already well entrenched within the community (see PicoContainer's discussion of the topic [1]).

paul@paulhanke.com 128.244.96.190 (talk) 18:42, 3 March 2006 (UTC)

It seems to me that IoC is simply a specific form of the Observer pattern as described in the Gof4 Design Patterns book. The defining attribute being what you described - a third party framework or library is the event notifier (or subject) and the application specific code contains the event listener (or observer). As far as the difference between Dependency Injection and IoC, you never really explain it. You simply state that Spring uses IoC to do Dependency Injection, which doesn't explain much to me. However, in the Fowler article [2], the author explains the origins of the term "Dependency Injection". He states that the difference with IoC as used by these "new breed" of containers is "about how they lookup a plugin implmentation" In other words, the distinction of IoC has become to mean that it uses the Observer pattern to specifically define the instantiation of plugin objects ("plugin" seems to imply objects that are both independent of the application code and the framework"). He calls this "inject(ing) the implementation". He goes on to state, "Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we setteled on the name Dependency Injection." To summarize, IoC is a subset of the Observer Pattern in that the event notifier is a third party framework, and Dependency Injection is a subset of the IoC concept in that the framework specifically uses the Observer pattern to define (or inject) a specific implementation of an interface. For me, these new frameworks seem to be motivated by the recent proliferation of various third party libraries that seem to change in popularity every 3 - 5 years. - Paul Lee

Personally, I'd look at it the other way around - that the Observer pattern is a special case of IoC ... I say this because the act of "registering" for IoC callbacks can be either explicit (e.g., a method call) or implicit (e.g., implementation of an interface or convention) and the callbacks can have arbitrary semantics; whereas registering for callbacks under the Observer pattern is always explicit and the callbacks have a restricted semantic interpretation (the Observable's state has changed).

Anyhoo (and to confuse things even further), here's another thought: is "IoC Container" a misnomer? - in a word: no. The term "container" suitably limits the scope to component lifecycle-management events. In that sense, EJB and the Spring Framework are both exemplars of IoC Containers, as they both make lifecycle-management calls into user code. The main difference between EJB and the Spring Framework in this respect is this: EJB requires heavyweight activation management (explicit activation, deactivation, pooling, etc., callbacks) for all managed components, but leaves dependency management to the user code (assisted via JNDI); whereas the Spring Framework focuses on lightweight ("non-intrusive" JavaBeans-convention-based) dependency management and makes heavyweight activation management a user option. -- Paul H.

Paul H., your rationale is based on the observation of how listeners (IoC callbacks) are registered. However registration of listeners is an implementation detail that doesn't define the Observer pattern or (from what I can tell) IoC. In the Gof4 book, there is no mention of how listeners should be registered, merely that they can be registered. From my interpretation, what defines the Observer pattern is simply that a subject notifies some registered listener(s) (observers) when the state of the subject changes. As far as I can tell, this is what IoC and Dependency Injection do. The common theme of IoC in all the references cited is that a "framework", which isn't part of the main application code, is responsible for the notification. In other words, the "framework" contains the subject, not the application code. This is the inversion aspect. The framework calling the application instead of vice versa. This is why Fowler seems to deride the use of the term to describe the new breed of frameworks, since most all libraries use some event notification system. (javscript, AWT, MFC, etc.) Hence the term "Dependency Injection" was coined to further differentiate these new breed of frameworks by describing their ability to "inject the implementation" of a class or interface. Regardless, the main issue is that the entry doesn't seem to describe IoC or Dependency Injection. Rather, it describes Dependency Inversion. Something completely different. - Paul Lee

"Regardless, the main issue is that the entry doesn't seem to describe IoC or Dependency Injection. Rather, it describes Dependency Inversion. Something completely different." Are they all completely different? I guess it depends upon your perspective ;-) -- but they're all certainly related. According to Martin's paper ("The Dependency Inversion Principle"), Dependency Inversion essentially boils down to coding lower level objects to interfaces in order to allow transparent component substitution (which, at the risk of adding more jargon, could be lumped under the modern heading of "Component-Based Design"). Martin's "inversion" seems to be this (direct quote): "ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS." In that respect, interface/component-based frameworks are implementations of both the Dependency Inversion and IoC principles; and Dependency Injection is but one (IoC-based) mechanism for assembling (the components of) an application whose design is based upon the Dependency Inversion principle. :-) -- Paul H.

IoC may be a subset of Dependency Inversion or use Dependency Inversion, but they are not equivalent. You wouldn't say IoC and Dependency Inversion are interchangeable terms anymore than IoC is OO Design, Web Frameworks, or Java. However, the article is treating them as if they are. If you feel they are rightly equivalent, you need to provide citations to support this. The only citation I could find is the one written by the article's author. The Martin quote you use shows no relation to IoC and Dependency Inversion anymore than Dependency Inversion is related to any number of design patterns that use interfaces or polymorphism. (BTW the quote is just a confusing way to say program to interfaces and abstractions) Futhermore, the article completely avoids describing the essence of IoC, which I think you define well enough in the discussion thread below. -- Paul Lee 199.10.231.124 (talk) 23:26, 26 April 2006 (UTC)

References to Dependency Injection and Inversion of Control

The more I read on the subject, the more I can see why this topic is so confusing. It seems the main proponents of the terminology never formally define Dependency Injection nor Inversion of Control.

In most of the articles that mention Inversion of Control, clear definitions are lacking. They never state what Inversion of Control "is" rather they tend to describe what it does or what it's related to.

The earliest referenced article by Fayad and Schmidt [3] states:

The run-time architecture of a framework is characterized by an 'inversion of control.' This architecture enables canonical application processing steps to be customized by event handler objects that are invoked via the framework's reactive dispatching mechanism.

More of a description of what it does than a definition and it sounds like a description of the Observer Pattern[4].

Inversion of Control as mentioned by Johnson and Foote [5] states:

One important characteristic of a framework is that the methods defined by the user to tailor the framework will often be called from within the framework itself, rather than from the user's application code. The framework often plays the role of the main program in coordinating and sequencing application activity. This inversion of control gives frameworks the power to serve as extensible skeletons. The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application.

Which isn't much of a definition so much as a passing remark. However we see the common theme of the framework calling the application.

Fowler continues this theme[6]:

The question, is what aspect of control are they inverting? When I first ran into inversion of control, it was in the main control of a user interface. Early user interfaces were controlled by the application program. You would have a sequence of commands like 'Enter name', 'enter address'; your program would drive the prompts and pick up a response to each one. With graphical (or even screen based) UIs the UI framework would contain this main loop and your program instead provided event handlers for the various fields on the screen. The main control of the program was inverted, moved away from you to the framework.

This again seems to be describing use of the Observer Pattern. However, it seems this may only be an example of one way Inversion of Control is used.

Rod Johnson who is responsible for the Spring Framework seems to paint the broadest stroke [7]:

The centralization of workflow logic into the abstract superclass is an example of inversion of control. Unlike in traditional class libraries, where user code invokes library code, in this approach framework code in the superclass invokes user code. It's also known as the Hollywood principle: "Don't call me, I'll call you". Inversion of control is fundamental to frameworks, which tend to use the Template Method pattern heavily

Adding the Template Method pattern as an example of Inversion of Control begins to broaden the definition. This implies that any time the framework code calls application code, it exhibits an Inversion of Control. I think this is the description that is most accepted today.

It seems however that this makes the term too broad. Fowler observes that the "new breed" of frameworks aren't differentiating themselves enough by using this term. So he coined the term "Dependency Injection" to make this distinction between the "new breed" of frameworks and what they are advertising as Inversion of Control and what Inversion of Control seems to have become to mean:

For this new breed of containers the inversion is about how they lookup a plugin implementation ... Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection

Unfortunately this isn't much of a definition of Dependency Injection either. From what I can tell, Dependency Injection describes when a framework inserts a concrete object into application code where the concrete object is independent of both the framework and the application code. -- Paul Lee

"From what I can tell, Dependency Injection describes when a framework inserts a concrete object into application code where the concrete object is independent of both the framework and the application code" ... I wouldn't go as far as saying that the concrete object is independent of the framework and application code - especially when you're talking about frameworks such as Spring, the concrete objects can be (and typically are) provided by the framework, the application, or both. Recall that what we're really talking about here are dependency-management mechanisms (DI being the IoC-based one) for managing object dependencies in an interface-based application (framework) - i.e., if a concrete object does not implement an interface that has been specified by the framework or the application derived from the framework, then it can't be successfully "injected"!

Anyhoo, here's another way to think about IoC (condensed and paraphrased from Schmidt's editorial "Building Application Frameworks"): an "Application Framework" implements the abstract structure (or architecture, if you prefer) for a class of applications (e.g., decision support systems). Application code extends and specializes (via class inheritance, implementing an interface, etc.) the abstract structure implemented by the Application Framework into a concrete application. However, it is the abstract structure of the Application Framework that provides the control regime for the application - i.e., the Application Framework decides when and where different architectural elements (as realized through application code) need to be invoked and the sequence of their invocation. This is the IoC principle in action within the context of an Application Framework. Obviously, this is different from how the IoC principle is applied within the context of a dependency-management (DI) framework, or within the context of a middleware framework, or even within the context of the Observer pattern - which is why Fowler states that IoC is much too broad a concept to be used to describe dependency-management. -- Paul H.

if a concrete object does not implement an interface that has been specified by the framework or the application derived from the framework, then it can't be successfully "injected"! You can simply use an adapter that acts as a translator to the applicaiton interface and the plugin object, as mentioned in the Martin paper: we might have dozens of such services and components. In each case we can abstract our use of these components by talking to them through an interface (and using an adapter if the component isn't designed with an interface in mind). In addition, frameworks seem to rely on a reflection mechanism to decouple themselves from the plugin objects. Ostensibly this is why they use reflection so extensively.

Anyway the problem I see is defining IoC and it's offshoot, Dependency Injection. My conclusion is that it's not clearly defined except for it's association with the "Hollywood Principle", which itself isn't clearly defined. The term IoC seems to be associated with almost everything as evidenced with this discussion. I've searched the literature cited, but haven't found any clear definitions. (i.e. something that tells me clearly what IoC and Dependency Injection are and what they are not). If anything, I think this ambiguity needs to be noted in the article. Your asides (anyhoo's) while interesting points, don't really help clarify the concepts. Similar to the cited articles, the problem I have is that you state IoC and Dependency Injection do this or this is an example of IoC and Dependency Injection, but never actually define the term. The current article describes Dependency Inversion okay, but doesn't concur with the cited articles that make references to IoC and Dependency Injection. These terms seem to go beyond simply programming to an interface. If we say the terms are equivalent, then we basically say that anytime you code to an interface, we are using IoC or Dependency Injection. However, IoC and Dependency Injection are relatively new terms that are most often associated with 3rd party frameworks. Programming to interfaces, from my experience, has been a concept almost as old as polymorphism. The point of this sub-topic is that the blame for this confusion seems to lie with these articles, which although influential are unfortunately rather obtuse. - Paul Lee

Ah, well - I was thinking that a few examples would help to shine a light into the dark corners that are always left by more succinct definitions ... as for the latter, here goes one attempt:

* Inversion of Control (AKA the "Hollywood Principle"): a style of software reuse where the control regime is implemented within the reusable software as opposed to being implemented externally in application software. That is, the reusable software controls the execution of the application and makes calls into application software as opposed to the more conventional opposite. ("Don't call us; we'll call you.")

* Dependency Injection: a style of dependency management that employs the Inversion of Control principle.

- Paul H.

P.S. "You can simply use an adapter that acts as a translator to the applicaiton interface and the plugin object, as mentioned in the Martin paper" - that's an overly simplistic way of looking at things, don'tcha think? - it pretty much implies that the only kind of incompatibilities that exist are syntactic incompatibilities ... much (if not most!) of the time, however, the incompabilities are semantic - in which case, an "adapter/translator" starts implementing complex functionality and becomes a component in its own right ... for example (sorry! - gotta use one!), would you consider an industrial-strength RDBMS to be just a simple adapter to the host file system? ... (never leave a succinct statement standing when there are hairs to be split! ;-)

Better Definition Sought

Moved from topic above. - Paul Lee

Ah, well - I was thinking that a few examples would help to shine a light into the dark corners that are always left by more succinct definitions ... as for the latter, here goes one attempt:

* Inversion of Control (AKA the "Hollywood Principle"): a style of software reuse where the control regime is implemented within the reusable software as opposed to being implemented externally in application software. That is, the reusable software controls the execution of the application and makes calls into application software as opposed to the more conventional opposite. ("Don't call us; we'll call you.")

* Dependency Injection: a style of dependency management that employs the Inversion of Control principle.

- Paul H.

I think the definition is a good stab, but I have some issues:

Inversion of Control (AKA the "Hollywood Principle"): a style of software reuse

I would just call it a software design concept since it's main purpose isn't software reuse.

where the control regime is implemented within the reusable software as opposed to being implemented externally in application software.

This implies that application software and reusable software are mutually exclusive terms. However, any code can be reusable, including application software. I would use "code library" instead. In addition "control regime" is a rather ambiguous term that begs clarification.

That is, the reusable software controls the execution of the application and makes calls into application software as opposed to the more conventional opposite. ("Don't call us; we'll call you.")

This statement may be a clarification, but this and the parenthetical statement are mostly redundant. We should be able to define it well enough the first time.

Here's my take:

Inversion of Control (IoC) describes a software design concept where a developer's code is called by an independent code libaray and the initiation of the call or calls is not controlled by the developer's code.

Dependency Injection describes a software design concept where objects are instantiated into a developer's code using Inversion of Control in order to allow the specific type of object to instantiate to be determined and managed outside of the developer's code.

- Paul Lee

"I would just call it a software design concept since it's main purpose isn't software reuse."

No? Here's a question then: why is it packaged as a reusable library? :-)

List of practices that *could* be considered as part of the IoC puzzle

In an attempt to bring this discussion closer to a formal definition of Inversion of Control I list a number of practices and principles that could be considered as forms of IoC. I've split the list in three parts:

• the first part is called dependency injection and encompasses those practices where dependent or collaborating objects are passed.
• the second part is called callbacks and encompasses those practices where code is injected into a framework or container for later execution.
• the third part is called support and encompasses those practices where some form of management is done for managed objects, reliefing objects from the responsibility of having to cater for these management services.

Dependency injection practices:

• Creating objects through constructors and at the same time passing in collaborating objects (constructor injection).
• Calling member properties to pass in collaborating objects (setter or property injection).
• Calling static or member methods and do something with the return value and at the same time passing in argument values (no common name, maybe factory method injection?).
• Assigning static or member fields to set collaborating objects (field injection).

Callback practices:

• Passing an object that implementats an interface or class to a framework method, field, property or constructor. The framework can call methods on this object at its own discretion (but usually through a well-defined contract).
• Callback methods on managed objects that get called by the container. An example in J2EE is the init() method on javax.servlet.http.HttpServlet, other examples can be found in the EJB specifications.
• AOP advice, interceptors and error triggering that get called when a joint point is reached during the execution of an application.
• Marker interfaces that when detected on a object during the execution of an event instructs a framework to take some action.

Support practices:

• Lifecycle management: a framework implements a lifecycle through which each object that's managed by the framework goes. For example, the Spring IoC Container supports these steps in chronological order during in its lifecycle implementation:
  • pre-object creation callbacks
  • object creation and constructor injection or factory methods injection
  • detection of one marker interface to pass the container object to the managed object
  • post object creation callbacks
  • property and field injection
  • pre-initialization callbacks
  • initialization via marker interface or arbitrary method invocation
  • post-initialization callbacks
• Value conversion: converting source-objects to target objects. These target object is detected by the framework. The Spring Framework uses PropertyEditor classes for this purpose.

After having written down this list I think one this is clear: Inversion of Control is only available for managed objects thus always assumes the presence of a framework or container.

Added expert tag

This article is in need of expert attention. The talkback page actually contains more valuable information than the article which does little to explain what IoC is. One might infer action from Control. Dependencies defined in classes relates to no action so can clearly not be a good definition of IoC, yet the article doesn't move beyond this point.

• IOC is nothing more than the template method: see GOF's chapter on the template method where they speak of "inverted control", "the Hollywood principle", "don't call us we'll call you", etc.

Hmm, the template method is a form of IoC. Saying that IoC is nothing more than the template method is clearly not correct.

The IoC is just a generalisation-mechanism to guarantee the conistency of an interface. Normally not required, but it is a good practice to always have a baseclass or an interface. This enables you later to use Factories, Remote, extensions to the interface, Singleton, etc. at one point.

That's so wrong: interfaces have nothing to do with IoC. Instead, IoC is about transfering control from any particular code to frameworks/containers.

Incorrect redirect

Dependency_Injection should redirect to Dependency_injection, not to Inversion_of_Control as is currently the case.

Please Contrast

The initial comment unfortunately made anonymously strikes me as important to address. I am having the same question or doubt: why so complicated? Particularly I am concerned when I hear "IoC Container" because that connotes "framework bloat" to me. This article should therefore clarify the minimum necessary things needed to talk about IoC or DI. What is wrong with the principle to, in Java:

• declare variables and members using only interfaces
• use any Factory such as Abstract Factory Pattern to obtain implementations
• avoid type-casting to implementations by using Strategy Pattern

To me, then, it sounds as if an "IoC Container" is just a fancy word for a system of factories. I believe this sort of abstraction should be a design principle rather than a tooling issue, and hence, I am weary of introducing the dependence to an elaborate "IoC Container framework", because it is hard, then, to reuse components accross different software projects. I believe in light-weight application of design principles.

It would really help me if someone could contrast IoC in the article with the minimalist approach. Because may be I am not getting the key points. Thanks very much. Gschadow 19:24, 4 January 2007 (UTC)

Code example

I think a great addition would be to show examples of the "common" methodology and the IoC methodology to show the distinctions. - Keith D. Tyler ¶ (AMA) 19:34, 7 June 2007 (UTC)

So basically

...the distinction to be made is that instead of the new object being responsible for grabbing its own resources, the calling/creating class feeds it its resources either at create time or later via bean methods.

What's not clear is why does there need to be a container framework for this practice? What does an IOC container provide? - Keith D. Tyler ¶ 17:11, 18 June 2007 (UTC)

That's exactly the point: you don't care. IoC is more than dependency injection, it's also callback interfaces and methods. The container or framework provides orchestration. Your code hooks into various points of this orchestration. Your configuration - if any - and programming - if any - tells the container or framework what to do but not how to do it.

IoC is also known as the Dependency Injection

If you actually read the Martin Fowler article you'll immediately understand that Dependency Injection is not a synonym for Inversion of Control. Rather, Fowler says it's a form of Inversion of Control. Great, the second line of this article is already wrong.

New attempt at rewriting Inversion of Control article

I think the current IoC article is worthless so I propose this rewrite:

Inversion of Control - also known as IoC - is a much debated topic in object-oriented programming. Although it misses a clear definition it's a defining idea behind a popular and mature software development framework: the Spring Framework. Many other frameworks written in many different object-oriented programming languages also claim to be based on Inversion of Control.

Inversion of Control can be seen as a concept that defines the relationship between an object on one side and a library, framework or container on the other side. It is the exact nature of this relationship that's the subject of much debate. There is a related debate about which other object-oriented concepts, principles and practices are or are not forms of Inversion of Control. Lastly there is yet another related debate that tries to determine whether Inversion of Control itself is a form of other object-oriented principles, concepts or practices.

Inversion of Control as a concept

Inversion of Control lacks a clear definition. Public discussions that attempt to come up with a definition tend to fail, typically because participants cannot agree on the nature of the relationship between an object and a library, framework or container. There is very little agreement on what is Inversion of Control.

Two other concepts are often considered to be related to Inversion of Control. They are Dependency Injection and callbacks or implicit invocation. According to some Dependency Injection and callbacks are forms of Inversion of Control. Other don't agree and claim Dependency Injection and Inversion of Control are synonymous [8]. Yet others are troubled by the inclusion of callbacks as a form of Inversion of Control. They claim Inversion of Control is synonymous to or a form of the Observer pattern (see discussions on the talkback page).

Inversion of Control as a set of design principles

Despite the apparent lack of agreement in the world of object-oriented developers about the nature and merits of the Inversion of Control this does not seem to hamper the popularity of libraries, frameworks and containers that claim to be based on Inversion of Control.

For example, the Spring Framework - widely regarded to be the most popular Inversion of Control framework - has been downloaded hundreds of thousands of times (as of June 2007) [9] [10].

Many more libraries, frameworks and containers claim to be based on Inversion of Control. It shouldn't come as a surprise that each framework promotes its own understanding of what constitutes as Inversion of Control.

Given the lack of a clear definition the next best thing for determining the boundaries of Inversion of Control is to look at how these frameworks are implemented and which design principles their developers and users consider to be forms of Inversion of Control. This is may not be the best way to come to an agreement. It does however provide a clue which design principles are considered by some to be forms of Inversion or Control.

List of design principles and their occurrences and implementation-specific details in various frameworks here

Inversion of Control in graphical user interfaces

Event-based graphical user interfaces are often developed by making extensive use of the Observer pattern. Objects that typically implement specific interfaces are registered with interface components. These components then call methods on these registered objects when an event occurs, for example when a button is clicked.

According to some this usage of the Observer pattern is a form Inversion of Control since there is a relationship between an object and a framework (the graphical user interface component). Other claim these are simply implementations of the Observer pattern.

Confusing Terms a Common Issue in Computer Science

I don't really see what all the fuss is about. There are many other concepts in computer science where one term means lots of different things. For example, client-server is about as confusing a term as you can find. Yet, there is a Wikipedia article on the subject. It doesn't even talk about the client server relationship that can exist between objects. My recommendation is to set up several sections, each of which describes one definition of IOC... and leave it at that KellyCoinGuy 05:00, 4 August 2007 (UTC)

Code examples

The text describing the code examples make it sound as if both code examples are IoC. Is that intentional? I didn't get any useful explanation of what IoC is from them. I'd need a contrasting example of what is not IoC to get something out of it. — Preceding unsigned comment added by 193.12.35.197 (talk) 11:53, 20 August 2013 (UTC)

Merge with Hollywood principle

I'm proposing to merge both articles, as both refer to the same concept. I think by having some examples that don't come from object orientation, this would help reduce the confusion with dependency injection, with which it's commonly mixed up. What do you think? Diego (talk) 12:25, 10 April 2014 (UTC)

Considering accessibility of the subject, like sometimes when there is an alternative view admitted in the field to which the matter is related, and as far as it is not about a simple truism that could be very shortly explicited, I tend to prefer a separate discussion for a problem vs. the legend associated with that problem. In my view, if it can be interpreted in the way of an aphorism instead of a truism it can deserve its separate article. I'm besides without indulgence for confusions between inversion of control and dependency injection, which for I am not able to find any semantic justification. --Askedonty (talk) 17:38, 10 April 2014 (UTC)

I'm not sure where are you aiming at with the distinction between truism or aphorism, but the term "hollywood principle" by itself doesn't have much weight beyond what's already at this article. If more sources are found in the future, a section could be kept at Inversion of control; if at some point there's enough material for a separate article, it could be split back to Hollywood principle. If there is no opposition, I will perform the merge. Diego (talk) 12:50, 29 April 2014 (UTC)

I agree with a merge and redirect from Hollywood principle to Inversion of control. Strebe (talk) 08:11, 12 April 2014 (UTC)

I agree with the merge with the option to recreate the Holywood Principle article, if that part becomes too long.--Sae1962 (talk) 07:40, 14 July 2014 (UTC)

• Great suggestion. I went ahead and redirected it; there wasn't too much special in that page but I added a couple things. II | (t - c) 01:40, 7 March 2016 (UTC)