Talk:Inversion of control/Archive 1

message: 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)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  Regarding the Terms and Definitions section 

message: 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)
thread_title:  Pretty clear to me 

message: 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)
thread_title:  AOP and strategy pattern 

message: "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)
thread_title:  Comments by Hamilton Verissimo 

message: 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)
replies: text: 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)
thread_title:  Resulting dependencies 

message: 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)
thread_title:  Regarding IOC Acronym 

message: 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)
thread_title:  Please Contrast 

message: 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)
thread_title:  Code example 

message: 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)
thread_title:  Confusing Terms a Common Issue in Computer Science 

message: 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)
thread_title:  Code examples 

message: 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)
replies: text: 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)
replies: text: 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)

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

text: 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)
thread_title:  Merge with Hollywood principle