Talk:Inversion of control

Archived Discussions

/Regarding the Terms and Definitions section: February 2006

Discussion before rewrite: October 2007

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)

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)

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)

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)

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)