Talk:Inversion of control/Archive 2

Archive 1

Archive 2

Archived Discussions

/Regarding the Terms and Definitions section: February 2006

Discussion before rewrite: October 2007

Suggestion to concise example

I was referring to 'references' links for an example. But I didn't find any sleek and concise example. Later I found one good link, please check here.

Rewrite -- motivation and idea behind

I took the liberty to completely rewrite the page, as the previous content was completely taken over by meaningless "object oriented" babble interspersed with Struts advertisments. I removed all of that, and instead wrote a pretty detailed description of the concept of inversion of control, as opposed to some very specific (yet, as the article helpfully noted, clear as mud at the same time) understanding of that term, which just happened to be used on many pages that also use "methodology" and "framework" a lot. As it's not doubt going to cause controversy, here are the important points I consider crucial for understanding the new version:

- I didn't use the word framework at all. This is because the concept of IoC has nothing to do with frameworks, but everything to do with control and inversion. Which is why I included code snippets to illustrate the issue at hand, as it's usually pretty easy to find control flow in code

- It is true that asking google about IoC provides almost exclusively hits related to "IoC containers" and "dependency injection". However, a quick look at Martin Fowler's page, after which all the rest seem to be modelled, reveals the opening quote that's basically nothing more than another version of the snippets I included in the article (I didn't look at Fowler's page before writing the article, btw). Keep that in mind before jumping to restore the references to dependency injections, as it illustrates pretty well what's the concept and what's just a specific application

- To be honest, it's not really easy to see what dependency injection is all about, because of all the pages after pages of Java constructors code and XML config files (huh?), however, it's not immediately clear what, if any, is the connection to IoC. Therefore I'd suggest that dependency injection be kept on its own page, which can be referenced from this page, as google presence sort of mandates that, despite the aptness or lack thereof of calling dependency injection IoC

- After the rewrite, the page is pretty similar to event-driven programming, which is not really surprising, as it's the most direct occurence of IoC one can find. Therefore it wouldn't be unreasonable to merge parts of the two, deleting the overlapping content and only keeping relevant sections of which. EDP's page can very well just delegate to IoC for most of the basics, or even be incorporated here as a subsection

Oh, and as a final note, the page needs some references, but I'm too tired to add that now. I will revisit the article tomorrow and update it with more substantial backup. mathrick 01:35, 3 October 2007 (UTC)

The re-write by mathrick is agreeable. However, at the same time I think we lost some valuble inforation which used to be there which connected the IoC concept and the frameworks which are built based on the principle of IoC. The contemporary usage of the term IoC most of the time refers to some sort of a framework. I hope this article will be expanded to include some of that based on the foundation laid by mathrick. Also note that Dependency inversion principle currently redirects to the IoC page. Now that Ioc page does not talk about Dependency inversion principle at all, I beleive it deserves its own page. Ritigala Jayasena 09:16, 3 October 2007 (UTC)

About rewrite

This rewrite didn't only erase the entire page, it has nothing to do with inversion of control. Event dispatching is a barely a form of inversion of control.

Considering all the valuable content that was on this page before and all the work that went into it I find is terribly rude to just erase everything. Unless I see some serious motivation as to why the original page should not be restored I will restore it very promptly!! —Preceding unsigned comment added by 62.102.20.9 (talk) 20:33, 29 October 2007 (UTC)

Another remark: Inversion of Control is very clearly related to object-oriented programming. I challenge anybody to come up with an example of inversion of control in a form other that object-oriented. Why does this page not make any reference to this?

How about Monads? IoC originated in OOP, but as an abstract concept it can be applied to other programming styles. Diego (talk) 08:24, 10 June 2008 (UTC)

Exactly. The monadic style consists of literally spamming code with callbacks, decoupling (error handling|mutable state|asynchronous events|multiple values) from the rest of the program. Is that not IoC? Lambda Fairy (talk) 02:57, 7 October 2012 (UTC)

A small quote from Fowler's article:

The examples I use are in Java, but like most of my writing the principles are equally applicable to other OO environments, particularly .NET.

Nowhere in his article does he make any reference what-so-ever to languages that are not object-oriented. This article is based on event-driven programming in procedural languages. This is totally unrelated to inversion of control since you're not inverting any control. You're merely pausing the execution of a thread or process. Do you call this inversion of control? What about ALL the other examples, some of which got erased? —Preceding unsigned comment added by 62.102.20.9 (talk) 20:45, 29 October 2007 (UTC)

It seems that when you say "Inversion of control", you are really thinking about Dependency injection. DI is a clearer and more appropriate term for that pattern, so I think you should work on expanding that article instead. See also this page: http://martinfowler.com/bliki/InversionOfControl.html --82.55.199.245 22:05, 2 December 2007 (UTC)

I assure you that when I say "Inversion of control" I do not mean dependency injection. DI is a form of inversion of control. —Preceding unsigned comment added by 213.189.190.8 (talk) 11:40, 8 May 2008 (UTC)

About rewrite II

I have to agree with the previous reviewer - Sense & Respond (event-driven programming) has no inherent relation to Inversion of Control ... certainly, many Inversion of Control frameworks use the concept of "events" to trigger the execution of code the lies outside of the framework, but there are other mechanisms as well (e.g., callbacks, delegation, etc.) ... likewise, it is possible to do Sense & Respond without Inversion of Control (e.g., listening and responding to operating system events; listening and responding to a pub/sub event bus; etc.).

Inversion of Control is a style of software construction where reusable, generic code controls the execution of problem-specific code with the strong connotation that the reusable code and the problem-specific code are developed independently (the reusable code possibly being sold as a framework by an ISV) and the result often being a single integrated application. —Preceding unsigned comment added by 128.244.97.10 (talk) 15:07, 7 November 2007 (UTC)

....................................................................................................... —Preceding unsigned comment added by 122.169.151.0 (talk) 08:01, 6 October 2010 (UTC)

About rewrite III

I agree with the two previous reviewers. Since the rewrite, I have to redirect all links to this IoC page and the "dependency injection" wiki page in my articles to somewhereelse. To average beginners, the rewriting made both pages hard to read and easy to be misleaded. I am not saying Mathrick's description is wrong. But I believe they are not appropriate to be written in wiki which is usually looked up by beginners as new concepts. I would suggest this page and the "dependency injection" page to be manually rolled back. Mathrick, if you have some indepth understandings on these two concepts, I would suggest you write them in your blog and put a link here after the rollback. —Preceding unsigned comment added by Kjin101 (talk • contribs) 18:32, 28 November 2007 (UTC)

Bullshit

Okay, so let's sum up. There are some disagree voices written in exactly the same style, one after another, by anonymous IPs and an account just created. The motivation given is that it's "clearly" not what the author considers to be the right definition, and that they have to link their articles elsewhere. Boo-hoo. Messages left for me are either stupidly inserted in comments (!? it was pure luck that I happened to look at this article's history precisely on that day) or inserted unsigned from anonymous IP, so there's no usable way to talk back. How about I just call bullshit on all of that? My version at least makes some logical sense and relates to the name "inversion of control" by, well, talking about inverted control. I don't really care how much Java has rotten your brain, but if you want to insert your frameworks, you have to give better arguments than your IP farm was able to provide so far. mathrick 22:04, 2 December 2007 (UTC)

Re: Bullshit

Mathrick, this is kjin101 (just in case the login session timeout)

Firstly, I would remind you watch your language and do not pollute the wiki community with your words ("bullshit" and "stupid"). If you have to say these words somewhere, I would very appreciate you could keep them in your personal blog. Thanks!

Secondly, two of my messages were indeed posted anonymously. However, the first one (the one inserted in comments) was before I even learnt how to register and how to use discussion and talk function, the second one left in your talk box last night (or this moring) was a result of forgotten to login. None of them were as you suggested to hide my identity. Even youself admitted that my three these messages (the above mentioned two plus the "About rewrite III" above with registered id) expressed the same opinion in almost similar style and words, rather than in different styles pretending to be made from different people. By the way, the "About rewrite I and II" are not mine (obviously you also know that).

Thirdly, all these three messages (anonymous or not) neither used any words like "bullshit" nor said your rewrite was "stupid". Instead, all of them were suggestions and recommendations gracefully. This represents some kind of respect to the wiki community and also to you, the previous rewrite, instead of simply replacing your rewrite with the original article or a new one (at least, you have no authority to prohibit others to do so). I don't see why you are not able to response these suggestions and recommendations in an equally respect manner but have to resort to dirty words? Are you believe this would prove you had the truth?

Fourthly, although I do Java programming sometime, I am primiary a C++ programmer and have more interest on IoC from C++ perspective.

I would give you a few days to think about and regret your behavior and make a public apology right here. Then we could discuss issues on why (or why not) you should move your rewrite to your personal blog. If you insist that your behavior and discussion langugage are appropriate in wiki community, I would have to report it to the authority and have to show your words when being questioned why I don't link wiki article in my IoC papers. (Kjin101)

I fully agree. The IoC article has been going through many reviews and rewrites. However, the version before the last rewrite was starting to look promising and seemed to include improvements made by several contributors.

This latest rewrite simply has to go. The author did not have the right to remove the entire previous version without discussing it with the community. The second-to last version of the IoC article is preferable to this version. If we can't find a way out of this I suggest we put the entire subjec (IoC) up for deletion. —Preceding unsigned comment added by 213.189.190.8 (talk) 13:22, 8 December 2007 (UTC)

Deletion of an article should not be seen a way out of this kind of situation. Can we come to some kind of reasonable compromise on the content and structure of the article? I'm more than willing to have a go at merging the content of the two, if applicable (and the community here agrees). --pipeline (talk) 01:10, 9 January 2008 (UTC)

ちょｗｗおまｗｗｗ

「ウィキペたん」ってｗｗｗｗ —Preceding unsigned comment added by 207.171.191.60 (talk) 18:07, 5 December 2007 (UTC)

Suggested Deletion

I suggest this article and dependency injection be deleted. There is absolutely no reason why Wikipedia must have an article for every halfway interesting observation of Martin Fowler that is bandied about in the computer programming trade journals for a few months. Don't get me wrong---I think he has done some great work, but I think he has produced a HUGE AMOUNT of work and a small percentage of it is notable enough for inclusion on Wikipedia. IoC is NOT one of those concepts. The support Fowler gives that this is a "notable" phenomenon is thin at best. Neither of these articles give ANY INDICATION of the notability of the concepts they describe. Please discuss. Mistercupcake (talk) 06:56, 29 December 2007 (UTC)

Both IoC and Dependency Injection are important computer science topics in object-oriented programming. Therefore I believe they should not be deleted. This article has to be re-written though. —Preceding unsigned comment added by 87.66.219.143 (talk) 13:22, 30 :December 2007 (UTC)

At the outset, note that I am employed as a Java programmer in a software house producing large enterprise and government systems. I use IoC frameworks on a daily basis. Please bear this in mind, as I am sure it will colour the remarks I am about to make.

There is profligate use of event-driven programming in large numbers of current user interfaces across a range of devices. The algorithm designs and mechanisms for creating event-driven programs are well known. This being the case, IoC as a concept could be regarded as a rewording of event-driven programming, and by this criteria may not be notable.

It may be considered notable by other metrics, however. If we allow the argument that we cannot divorce the concept of IoC from some reasonable example of usage, then one of the most common IoC frameworks would be Spring. Statistics on the uptake of Spring in the Java enterprise community may be available; Spring appears to be synonymous with IoC in this community. If this community is notably large, it would seem to following that IoC would be a concept familiar to reasonably large number of people, probably large enough to make it notable by itself. I believe (but have no evidence) that IoC is also known to programmers of other languages, and of different frameworks.

From my own personal experience, I was taught about IoC two years ago during my Bachelor of Computing degree at the University of Tasmania.

I think it credible to suggest that enough programmers are aware of IoC in some way that it be kept as an article.--pipeline (talk) 05:09, 8 January 2008 (UTC)

I'd keep the article too since wikipedia is always the first place were I'm looking for definitions, but would like it to be changed. I didn't get the point of IoC from reading this article. Write it shorter and set a link to (http://martinfowler.com/bliki/InversionOfControl.html). —Preceding unsigned comment added by 89.41.207.48 (talk) 15:59, 28 January 2009 (UTC)

Intro Paragraph and Dependency Injection

I disagree with removal of dependency injection reference by "m". Yes, dependency injection has it's own article, but dependency injection containers are called "IoC containers" for a reason. However, the "IoC" in "Ioc Containers" is not exactly the same as "IoC" described here. So, it seems to be in order to explicitly clarify the ambiguity.

Also, the wording of the current intro needs some improvement. In my world a sentence like "=let some external entities take over the control over the precise order and set of events to happen=" sounds more like a riddle than an explanation: it requires too many passes to parse. —Preceding unsigned comment added by Ivankriv (talk • contribs) 05:21, 7 March 2008 (UTC)

Up for deletion: about the removal of the previous version

Given the previous version of the IoC article - which was promising yet needed more work - has been replaced overnight without discussion I suggest this article is deleted for this reason. The history of this article and the events that have led to the current version for me are sufficiently alarming to warrant a delete. —Preceding unsigned comment added by 213.189.190.8 (talk) 11:17, 31 March 2008 (UTC)

Use of "programme" spelling distracting

Why are we using the spelling "programme"? Does this have some special meaning distinct from "program"? If so, should it not be clearly illustrated? I'm reading this and every time I read that word I think "what's this? what does that mean? why is it not spelled program?".

It's just distracting. And who spells it like that anymore anyway. Logan1337 (talk) 03:04, 15 April 2008 (UTC)

The "correct" and accepted British spelling of program in the context of computer programming is program. In all other contexts, it is programme. (Analogue vs. analog is a similar exception.) However, to avoid an edit war, I have refactored all sentences that contained the word. Now maybe we can focus on fixing the content of article, which needs a lot of work. For example, it should explain things in a way that makes it clear how IoC differs from event-driven programming and dependency injection. Maghnus (talk) 18:56, 9 June 2008 (UTC)

Good work at biting the bullet! :-) Diego (talk) 08:29, 10 June 2008 (UTC)

Ok spelling aside, I have a problem with the actual content of this article.

I read the whole thing and fail to see how this "inversion" is anything new or even noteworthy. Frankly, the "inversion" seems to be the normal case! If anything, strict serial-input/output should be the inversion.

This is how computer programs work today: the user clicks a button and the program responds. That's supposed to be a new idea?! That's "inversion" of something? Well let's be serious here. For all that, you can write a command-line program that demonstrates this "inversion" just by asking for a command. The command is not known in advance and affects the order a supposedly "normal" or "traditional" program would follow so it must be inverted!

I fail to see how this is an "inverted" anything, save for the original computer programs written 50 years ago.Logan1337 (talk) 03:17, 15 April 2008 (UTC)

Definition and overlap with similar subjects

I've reworded the leading paragraph, and tied together some examples to illustrate how IoC is a generalization that matches all them. Does my interpretation correctly describe what the IoC concept represents, or am I missing something important? Diego (talk) 08:29, 10 June 2008 (UTC)

There is also a great amount of overlap with the related concepts such as Hollywood principle, dependency injection, Dependency inversion principle, Event-driven programming, Software framework, callbacks, maybe the Visitor pattern... could we create an overall structure or category for all these related articles, centralizing the core idea in just one place and leaving the specific articles to describe the differences between them? Diego (talk) 09:45, 10 June 2008 (UTC)

Design pattern?????

How is IoC a design pattern? I have never seen it expressed in the specific format that defines one. It's always explained as a design guideline or principle, not with the specific sections (intent, forces, structure, implementation...) that a concept must include to be called a a design pattern. Diego (talk) 09:26, 16 June 2008 (UTC)

To document my posture, see http://wiki.apache.org/avalon/WhatIsIoC: here IoC is expressely described as "not really a design pattern". Diego (talk) 09:41, 16 June 2008 (UTC)

Hold your horses. Since when are there rules for something to be a Design Pattern? Did I miss something? Christopher Alexander's Pattern Language is exactly the opposite of strict rules. —Preceding unsigned comment added by 84.192.122.222 (talk) 19:13, 16 October 2008 (UTC)

They are not strict rules, but they have a particular format: "a formal way of documenting a solution to a design problem". Design patterns typically contain a standard set of sections (name, description, forces, implementation details, relation to other patterns). Diego (talk) 13:51, 9 December 2008 (UTC)

Indeed. At the very least, scientific articles about design patterns follow (more or less strictly) a structure resembling the patterns in the GoF book.

Here are a few links where Ioc is used in design pattern terms. Some may be more related to DI though. http://msdn.microsoft.com/en-us/library/cc707904.aspx

http://www.codeproject.com/KB/aspnet/IOCDI.aspx

http://msdn.microsoft.com/en-us/magazine/cc163739.aspx

http://martinfowler.com/articles/injection.html

--Jpvosloo (talk) 13:50, 8 December 2008 (UTC)

Thanks, I had never seen the concept explained in Design Pattern format before. Those links seem to describe just the "Dependency injection" and "Service locator" varieties. I'd still define IoC as a general principle encompassing all them. Diego (talk) 13:51, 9 December 2008 (UTC)

Indeed. The second MSDN article never mentions inversion of control. The article on codeproject does not qualify as a reputable source, if nothing else by the quality of writing and formatting (and the content does not look more authoritative). And the first MSDN article, which is the only description in pattern format, and which describes just two actual related patterns (Dependency injection and Service locator), references (I would say as a source) Martin Fowler's article. He also wrote another article, describing Inversion of Control: http://martinfowler.com/bliki/InversionOfControl.html. The Martin Fowler's article you mention [1] explains that he uses 'Dependency injection' for the pattern that people used to name 'inversion of control' but which was not the original idea.

Rewriting this article

Hello, I think the definition of Inversion of Control is not described properly in this article. Inversion of Control is not the most apt term either. It refers to 'habits in the past', when programs were written procedural style. The OOP community had to learn OO themselves. Inversion of Control is actually the description of what itself is not, not what is by itself. This opens the door to a variety of opinions and misunderstandings about what Inversion of Control is. It is at the core of how it is defined. Nevertheless, the term is known and can be used anyhow. I rephrase it for myself as 'Handing over Control'. 'Handing over Control' describes in my opinion in essence what Inversion of Control is all about. First is that the decision about the exact implementation is postponed to run time. Second that after making a call using this principle the caller can not make any assumption about what is happening next. The caller will get a predictable result, otherwise it can not use the result, but how the result is produced is completely the responsibility of the callee. Therefore inversion of control is also about 'Let do others best, what they can do best. In the mean time I will concentrate on what I can do best.' Using a principle of Inversion of Control creates the awareness that the execution of tasks should be controlled by the expert in the execution of the task, which in a computer program is the task itself. A factory pattern just as a service locator just as the three injection methods are valid patterns using Inversion of Control as its principle. That is why it is more a architectural guideline then a design pattern. There are more design patterns, which can be used to implement Inversion of Control. I would like to rewrite the information in this article. Preferably this week. On the other hand I do not like to just overwrite and delete someone else work. How to continue? Any suggestions? Is it a good idea to create a page 'Handing over Control' or will that mess up more then it might help?

With kind regards,

Loek Bergman Loekbergman (talk) 13:16, 13 May 2009 (UTC)

While improvements in the text of the article are very welcome, we have to be careful to avoid original research. I do not know whether the term "Handing over control" that you have proposed is a common term, but, if it is a term that you have invented and if it is not popular yet, you cannot add it to the article nor create an article about it, otherwise it would be original research, something forbidden here according to the Wikipedia policies.

Other than that, I think your points about the fundamental characteristics and qualities of Inversion of control are very welcome to this article.

My suggestion to you is: Be bold and change the article. If someone disagrees with a certain change you make, he can partially revert it (explaining why) and we can always discuss it here in the talk page and find a consensus that in the end will bring us an improved article. --Antonielly (talk) 13:45, 13 May 2009 (UTC)

Totally changed the article. The original source saved on my computer. Loekbergman (talk) 16:22, 13 May 2009 (UTC) Hi, I saw that someone has changed the way I wrote the article. That is ok off course. But I would like to know why the phrase 'In the mean time I will focus on what I can do best' is left out. It adds value to the first part of the aphorism, which you can recognize in the second purpose. With kind regards,Loekbergman (talk) 17:29, 13 May 2009 (UTC)

Could the persons who are editing this topic please explain why? I saw some edits which did not describe what Inversion of Control is about. It is not something related specifically to event driven architecture. Event driven architecture is expected to use inversion of control, but it is absolutely not the other way around. Having a topic on EDA, IoC should be mentioned. It is not the other way around. Loekbergman (talk) 19:36, 13 May 2009 (UTC)

Hi Beland and SmackBot, I have been thinking about the lines you introduced. Really had to think about what you mend with the sentence about the flow of the programming. I think indeed that it is a meaningful contribution. I worked it out further as the original sentence seemed to be too short to transfer its meaning successfully. Sorry for my English as I am not a native speaker. I hope you agree with my modifications. With respect Loekbergman (talk) 21:25, 13 May 2009 (UTC)

Still needs cleanup

I'm not an expert on IoC, so unfortunately I can't add much to this article, but the following phrases are really bad and add nothing whatsoever to one's understanding of IoC:

"Inversion of Control however created hype as something new. It definitely raised the awareness for this architectural principle and gave architects a proper guideline to improve their work. Doing that it served its job well. In the world of Java, if not others, Inversion of Control has created its own namespace. Compared to 'abstraction by layering' it is a more specific term, which at the same time describes its purposes in a more concrete way. The term itself is not that abstract to say. It is to prefer when architectural terms would not be computer language specific."

I am very open to non-native English speakers editing these pages -- in fact, I wholeheartedly think they should. But this is a problem. The sentences barely flow logically and certainly sound awkward and stilted to a native speaker. I actually have to look for other sources of information on IoC, because Wikipedia is clearly not going to provide much help in this regard. --Seinberg (talk) 23:24, 15 December 2009 (UTC)

Title to be changed from "Inversion of control" to "Inversion of Control"?

I think the title of this article should be Inversion of Control. That is what all the sources use.

What do you think?

--Mortense (talk) 19:03, 4 March 2010 (UTC)

I fully agree.Loekbergman (talk) 08:49, 29 September 2010 (UTC)

I agree too. --Maxence.bonhomme (talk) 09:24, 4 October 2010 (UTC)

Macaroni Code

The article uses the term "macaroni code." This term is not explained, there is no Wikipedia article about it, and it's likely a much less commonly used term than "spaghetti code." The article should either explain what this term means, or avoid its use. ATBS 00:53, 11 March 2010 (UTC)ATBS —Preceding unsigned comment added by ATBS (talk • contribs)

It is indeed a term I use freely. In Dutch one is allowed to create new words and people will understand them if it presents a clear image. I think the same can be said of macaroni code. That is code in which all pieces of code are quite short, but there are so many pieces of short code and to understand one piece you have to look to a lot of other short pieces of code as well, that it is very hard to grasp what is happening where. This kind of code is typically for projects relying heavily on multiple layers of abstraction. Although it might be highly efficient, it can be very difficult to unravel. IoC is a principle which is on purpose and deliberately postponing responsibility of execution. That will make architectures, which rely heavily on IoC prone to the creation of macaroni code. Loekbergman (talk) 08:56, 29 September 2010 (UTC)

Merger proposal

Given the current state of this page (and we agree it is a mess), and given the close relation (acknowledged by the article) with dependency injection: ("Inversion of Control is highly associated with dependency injection and the dependency inversion principle."), either the articles should be merged, or the difference should be better explained. Even then, it might be better to have a single article explaining both (which could start from the other one). At some point, this article writes "In an article by Robert C. Martin[4] the dependency inversion principle and abstraction by layering come together.", when the topic is inversion of control, like if dependency inversion were the same thing. I have to admit that I looked into Wikipedia to get a better understanding of the subject, which I am currently getting elsewhere. I think I can see a difference and a relation, and I have yet to understand it in full. --Blaisorblade (talk) 20:05, 23 August 2010 (UTC)

I'm sorry, but I must strongly disagree. Althought their relations is close, it's simple because dependecy injection is a subtype of this principle. You see, Inversion of Control is the father of another ideas as well. Example: the [Object Context Control] —Preceding unsigned comment added by 200.130.5.50 (talk) 18:14, 17 September 2010 (UTC)

I agree that it is not advisable to merge these documents. I have added a reference to a document of myself to show you what is the difference. Not for self profiling. I wrote the base of this article on Wikipedia, but left out my own writing as I thought this is not proper. But when merging is considered I show an article in which IoC is presented different from being a design pattern. Dependency Injection is one of the possible implementations of IoC. Proper layering is another one. That is why I presented the example of a server facade. It is another design pattern then Dependency Injection while showing the essence of IoC.Loekbergman (talk) 09:39, 29 September 2010 (UTC)

Leave them separate. The topics are relevant for their own articles respectively. Dependency Injection is but one way of achieving inversion of control.80.219.16.188 (talk) 17:42, 11 November 2010 (UTC)

May I refer to a suggestion I previously made, not to merge these articles but to create an index for them? This would highlight the commonalities as well as the differences between these related concepts. Diego Moya (talk) 15:55, 25 November 2010 (UTC)

I came here from a recommendation to merge the Dependency Inversion Principal page with the Inversion of Control page. I do not believe it appropriate to merge these two topics. DIP concerns itself with specifically how dependencies are expressed between classes. While IoC is an implementation pattern for resolving and dependencies which can help satisfy DIP. They should probably mention each other. The suggestion to merge the two pages is similar to saying that you should use concrete classes instead of interfaces and abstracts. Quite the opposite of what the principal and pattern being discussed are trying to express. 63.71.3.45 (talk) 19:07, 16 March 2011 (UTC)

I'd also like to note that Dependency Inversion is not the same as Dependency Injection. —Preceding unsigned comment added by 63.71.3.45 (talk) 19:09, 16 March 2011 (UTC)

If inversion of control is, like the dependency inversion principle, also a principle for OOP, it should be merged. If it is more general, I am against a merger. Sae1962 (talk) 09:19, 13 April 2011 (UTC)

It is impossible to merge those articles, as IoC and the dependency inversion principle are two quite distinct things. Such a change would be apt to create confusion and likely just someone will porpose a separate article on IoC as a result. So please leave them alone! Unfortunately, dependency inversion can be clearly defined, whereas Inversion of Control is used very broad and with a variety of different meanings. This problem won't go away if we pretend these two terms would be equivalent. Ichthyostega (talk) 01:55, 30 April 2011 (UTC)

It should not be merged, as they are quite different topics. Inversion of Control is similar to the factory concept, dependency inversion principle is to move dependencies to a class instead of letting the class to create the dependent objects (see Inversion-of-control vs. dependency injection principle). Sae1962 (talk) 06:38, 2 August 2011 (UTC)

I propose we merge Inversion of Control (IoC) and Dependency Injection Principle (DIP). I can't think of a tangible code fragment or instance of design that illustrates IoC but not DIP or vice versa. Unless someone can come up with such an example, I think we have to conclude the two concepts are equivalent. Realizing absence of evidence isn't evidence of absence, my second argument comes from the two main references for each article. In his blog post, "InversionOfControl" Martin Fowler states that IoC is "often seen as a defining characteristic of a framework". In his book, "Agile Software Development" Robert Martin states that DIP "is at the very heart of framework design". The two authors seem to be talking about the same concept. Burrise (talk) 20:17, 31 August 2011 (UTC)

I understand the desire and sentiment for merging the IoC and Dependency Injection (DI, not DIP!) pages since they are very close in concept. There is confusion in our industry about the semantics, and any dispute that may have occurred among the experts isn't widely publicized. I think it's for that reason that the distinction is largely glossed over in the literature. However, in my opinion, we should nto make them a single page because I would like to characterize the distinction.

Though IoC and DI sepeartion can be debated, Dependency Inversion Principle (DIP) is a wholly different concept, that high-level components should not depend on low-level components.

You can accomplish Inversion of Control by implementing Dependency Injection and thus satisfy the Dependency Inversion Principle. IoC is not the only way to satisfy DIP, and there may be room to debate that DI is not the only way to implement IoC. (Hmm... that sounded good, maybe I should add that as an edit!) — Preceding unsigned comment added by Peoplemerge (talk • contribs) 17:19, 13 February 2012 (UTC)

I agree with you completely and the articles should not be merged. You should definitely create a section of "Confusion with similar concepts" or something like that and put your example. A principle is just a good practice, IoC is a programming technique (that complies with DIP) and dependency injection is a concrete design pattern (to achieve IoC)--Javierieh (talk) 19:57, 25 September 2012 (UTC).

The articles in question absolutely SHOULD NOT be merged, and I nominate the notice at the top be finally removed. Merging would create harm to readers attempting to learn about either concept, as each concept is distinctly its own despite the relationship with the other and they are not so closely related that they should be merged (I don't mind attempting to disambiguate the two further here if it's desired; I am a professional in the field). I suggest that anyone suggesting the articles should be merged does not fully understand either concept. If the cumulative opinion on this proposed merge is not yet enough to make a decision, perhaps we can reach out to some famous people in the software field for their professional discourse; some of the authors mentioned are not that difficult to converse with directly through Twitter or email. --justmikesmith (talk) 13:39, 31 May 2013 (UTC)

- As some have stated, first and foremost, DI != DIP, but they are related. Just because they share letters doesn't makes them the same! The "P" in DIP plastered all over the place is not a typo.

- DIP is inverting how most people think about dependencies. DIP (with a P) simply aims at saying that you should not rely on concrete details when designing, you should only rely on abstractions.

-Stupid example: Suppose you are writing a piece of code that converts a stream of data from ASCII to UTF (let's call this dumb example TextConverter). You should not just assume that the stream is just coming from a keyboard and therefore should do not start writing a class to read from the keyboard. Input can be coming from the keyboard, from the network, from another program,etc.. What you have to do is start with an abstraction called something like AsciiStreamReader which returns a stream of ASCII characters. This is where the "Inversion" in DIP comes from. Most people will start thinking about writing the concrete implementation instead of thinking about the abstraction/contract between components. So your design would be a TextConverter class that has a reference(s) to an AsciiStreamReader type which has been subtyped/extended by concrete implementations such as AsciiKeyboardReader, AsciiNetworkReader,etc... That way your TextConverter only knows that there is something out there that is returning ASCII data. It does not care WHAT or HOW. Which obviously makes your TextConverter class shielded from any side effects of the implementation details of any AsciiStreamReader and you can use the same TextConverter to convert all kinds of streams.

- IoC can be, and is popularly implemented using DI (no P!) which is why the terms IoC and DI (again no P!) are used interchangeably. IoC *helps* in achieving DIP (with a P). For example in Spring, you would ask the framework to inject into the TextConverter object an/some/all AsciiReader(s). The Spring container will look for something that implements AsciiReader and inject it into your TextConverter object. You do not care WHAT implements it nor HOW it is implemented. Your object just needs something that implements AsciiStreamReader and the IoC framework will get it for you. — Preceding unsigned comment added by Momo654321 (talk • contribs) 21:10, 27 October 2013 (UTC)

Rewrite proposal

IoC is a coding pattern to break mutual/circular component dependencies, where these dependencies are unavoidable even granted a proper design.

I concurr with the essence of the rewrite proposal originally by users:

- mathrick 01:35, 3 October 2007 (UTC) - Ritigala Jayasena 09:16, 3 October 2007 (UTC)

And I too believe the current article is totally off mark, no wander that there are merge proposals...

IoC deserves an article, action should be taken to revert the current one to a more sensible base.

LudovicoVan (talk) 12:19, 10 April 2011 (UTC)

Problem lies in the (historical) use of the term itself

While it is clear, that Dependency inversion and Inversion of Control are distinct terms, there remains a real problem. Dependency inversion is clearly delineated and defined. To the contrary, Inversion of Control was a real buzzword some time ago. It had a magical feel and was often used to outline a very fundamental principle, similar to the Subsidiarity principle. Unfortunately then in the next years several authors tried to concretisise this magical term and in turn defined it to be equivalent with Dependency Injection, Dependency inversion (and I vaguely recall even further definitions). Thus, meanwhile, unfortunately IoC got a term similar loaded and fuzzy like cloud computing. Thus, I think the only viable approach to handle this page for IoC properly would be to take a historical approach and try to identify and quote the most prominent mentions and the historical impact of the term IoC (which was very important in the early days of Exctreme Programming)

Ichthyostega (talk) 02:02, 30 April 2011 (UTC)

Well, if for you the early days of XP belong to history (to me XP was born just yesterday), then no wonder that you think IoC was only a buzzword with a magical feel. On the contrary, not only IoC has a very specific meaning, it also comes way before DI and, as someone was already saying above, DI is actually a specific form of IoC. The current article is just totally off mark. - LudovicoVan (talk) 21:50, 24 November 2011 (UTC)

2012 Rewrite

First, this article needed to identify the coupling relationship and how it occurs clearly and upfront using an assembler for assigning compatible abstractions. I've taken the liberty of cleaning this up so I hope this modification is to the liking of you, the community.

There is not much dispute that IoC is about OOP, so I reworked the introduction to highlight that. I was first introduced to IoC as a design pattern, but I'll concede the fact that it may be more of a principle or practice than a pattern, particularly since dependency injection is indisputably a pattern, and IoC as a concept has always held the notion that control flow occurs in a decoupled fashion. Edit: Martin Fowler calls it a pattern: '... a common pattern to how [wiring is performed], a concept [referred by] the very generic name of "Inversion of Control". In this article I dig into how this pattern works, under the more specific name of "Dependency Injection", and contrast it with the Service Locator alternative.'

I agree wholeheartedly that there's a problem with the terms IoC and DI, but I contend the problem is that there's lack of a unifying distinction in the community's language between them.

There is much more work to bring this up to wikipedia standards. There's rambling that mixes up other OO principles such as dependency inversion.

I agree with Martin Fowler... Edit: I reread Martin Fowler's original article http://martinfowler.com/articles/injection.html and it seems that IoC may not be as distinct from Service Locator as I had thought. Further http://martinfowler.com/bliki/InversionOfControl.html does delineate these further by drawing the distinction between the "general principle" (IoC) and a "specific style" (DI).

Although I like the examples using generics, we should have better examples using at least Spring IOC and Guice, and probably a simple handmade assembler class by itself. Edit: perhaps that go under DI, and here we should provide a handmade assembler using DI and Service Locator. Also I read the generics example and I'm increasingly convinced they demonstrate delegation through a callback, not IOC using DI or Service Locator through an assembler. Also I think Factory doesn't belong here.

Please write comments! If feedback's positive, I'll continue to revise.

Peoplemerge (talk) 20:03, 13 February 2012 (UTC)

About the fact that "there is not much dispute that IoC is about OOP"... I don't think it's right, unfortunately. In fact, when IoC is explained in its broadest sense (which happens to be, when a semantic difference with DI appears), it's usually not in an OO context. The typical example is like Fowler's [2] having to do with some hypotetical old-styled GUI code vs. Tk code. It's like Fowler is saying, IoC is an old principle that we began to use widely with GUIs. Nowadays, that same old principle is the backbone of OO frameworks, too. (It is unclear in which way exactly it is that same principle, which is like saying, it is unclear what the IoC is exactly. Following Fowler's reasoning, I would say that IoC is something informal from the point of view of the client programmer, like: "I won't use libraries, I will create plug-ins and plug them in". This too has nothing intrinsically OO in it. Moongateclimber (talk) 16:27, 13 October 2012 (UTC)

Sax and Dom

I don't think dependency injection has anything at all to do with the differences between sax and dom. Nothing at all in a degree I am amazed that someone can write such a statement. sax and dom are different approaches on how to treat an xml document, where the former is a kind of linear reading approach. Is this some kind of scam/spam with misinformation? — Preceding unsigned comment added by 80.71.133.167 (talk) 02:50, 13 February 2012 (UTC)

I think associating sax with IoC is surprising as well, but I do see an the link. Sax lets you create event handlers to the document to build your own object model. If all event-driven architectures are IoC then yes we can say sax follows IoC and dom does not, but further than that, I would need to think about it. Peoplemerge (talk) 20:02, 13 February 2012 (UTC)

Edit:

There is a VERYGOOD german article about the Dependency Inversion Principle. It covers this topic perfectly. I am going to translate the text, my german is good. We could use that entire article to have a good english one. — Preceding unsigned comment added by 87.149.139.244 (talk) 15:28, 6 March 2012 (UTC)

Sounds great! I'm looking forward to reading it. Just hope it clears up the DI vs DIP vs IOC lingo! Peoplemerge (talk) 6:53, 7 March 2012 (UTC)

The whole "APIs that use inversion of control" section is useless and misleading. In its broadest sense (that it, in its own sense) IoC is so wide a notion that the examples of APIs that use it are countless, starting with essentially any GUI toolkit at least from the 80s on, and essentially any OO framework. Unless there is an example of something that is very significant in its way of using IoC, it makes no sense to mention two examples. Moongateclimber (talk) 17:15, 13 October 2012 (UTC)

Old Talk References

I think this topic suffers because authors are using original research. i.e. their own understanding and interpretation, when we need to rely on original sources. And that is where the problem lies. The terms Inversion of Control and Dependency Injection have never been formally defined by the originators, and I suspect it's because it's simply an implementation of the Observer Pattern with the only distinction being that the events controlled by a framework (or third party code) as opposed to user action or the user's own code. What follows is my original post from five years ago when I was attempting to find the origin of the term. I hope this helps the discussion:

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. 199.10.231.172 (talk) 21:35, 26 September 2012 (UTC) Paul Lee

Wrong use of generics?

In the examples, aren't generics being used the wrong way?

public class ServerFacade {
	public <K, V> V respondToRequest(K request) {
		if (businessLayer.validateRequest(request)) {
			DAO.getData(request);
			return Aspect.convertData(request);
		}
    
		return null;
	}
}

How can the return value of DAO.getData(request); always be of the generic type V? DAO doesn't know anything about V, so either it has to be a DAO<V>, or V has to be a non-generic type. -- 78.52.188.12 (talk) 17:08, 20 June 2013 (UTC)