Talk:Inversion of control

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)

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)

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)