Diskussion:Inversion of Control

bitte löschen

IOC ist nur ein Buzzword für das registrieren von callback funktionen. Warum brauch dies einen eigenständigen Artikel??? (nicht signierter Beitrag von 78.35.129.119 (Diskussion | Beiträge) 02:24, 25. Mär. 2010 (CET))

Es fehlen Quellenangaben! 88.73.248.202 12:27, 20. Jan. 2007 (CET)

Ein Leser hat diesen Artikel als (Zitat)

bezeichnet. Ich denke er meint vor allem die im ersten Absatz erwähnte Gleichsetzung von 'IoC' und 'Entwurfsmuster', was leider wirklich unglücklich formuliert ist. In meinen Augen ist IoC ein Paradigma, eine Methodik, die dann mittels Entwurfsmustern realsisert werden kann. Ich (der Autor des zweiten Absatzes) bin auch für eine leichte Überarbeitung des ersten Absatzes.

Bearbeiter 'D' meint Käse und löscht

In einer früheren Version habe ich versucht eine Systematik der Realisierungen von IoC anzubieten:

Bei der Umsetzung des IoC-Paradigma unterschiedet man

• Realisierung mittels Service-Locator - abhängige Komponenten registrieren sich am Service-Locator und werden von den unabhängigen Komponenten über den Service-Locator gefunden und aufgerufen
• Realisierung mittels Dependency Injection - abhängige Komponenten werden während der Initialisierung der Anwendnung bei den unabhängigen Komponenten registriert (meist durch Constructor- oder Setter-Injection)

Ich beziehe mich in erster Linie auf den Artikel von Fowler (http://martinfowler.com/articles/injection.html)

... but I'll point out now that that's not the only way of removing the dependency from the application class to the plugin implementation. The other pattern you can use to do this (IoC, Anmerkung des Autors) is Service Locator, and I'll discuss that after I'm done with explaining Dependency Injection.

Vielleicht irrt ja Fowler oder ich verstehe ihn falsch!? Vielleicht kann jemand Licht ins Dunkel bringen. --Christian Dürr 18:20, 8. Mär 2006 (CET)

Martin Fowler bezieht sich auf Dependency Injection

Martin Fowler bezieht sich explizit auf den Begriff 'Dependency Injection'. Er selbst hat diesen Begriff zusammen mit anderen geprägt, weil 'Inversion of Control' zu allgemein ist. Es bedeutet genau das was hier im Artikel beschrieben wird.

Etwas unglücklich finde ich aber die Aussage, dass IoC in allen modernen Programmiersprachen, vor allem Java, verbreitet sei. Das hat nichts mit Programmiersprachen zu tun sondern mit Frameworks. Praktisch jedes Framework zur Erstellung graphischer Applikationen arbeitet mit IoC, z.B. Microsofts MFC, ein C++ Framework.

Die Aussage steht ja so nicht mehr im Text, aber was haben Callback-Funktionen mit Frameworks zu tun? Und was genau soll das mit moderner Sprache zu tun haben? Ich habe früher häufig Callbacks in C-Programmen benutzt. Nur weil das häufig mit Frameworks genutzt wird, ist ein Framework noch lange nicht die Voraussetzung. Voraussetzung ist eine Programmiersprache, die Verweise/Zeiger auf Methoden bieten kann. --80.153.250.36 13:37, 1. Sep. 2016 (CEST)

Tapestry 5 (beta)

Vielleicht könnte man an dieser Stelle noch das Tapestry Framework in seiner neuen (fünften) Version erwähnen, welches sehr stark auf IoC aufsetzt und sogar auf einem eigens dafür geschriebenen IoC Container basiert.

IoC ist keine Eigenschaft der Programmiersprache

"Somit funktionieren fast alle modernen Programmiersprachen nach dem Prinzip Inversion of Control": Diese Aussage ist falsch, denn unter C++, Java oder C# kann man ohne Probleme alles in seine eigene main() packen. IoC ist vielmehr ein Programmierparadigma, das in "Programmierframeworks" wie .NET oder der Java AWT Library zum Einsatz kommt.

"Inversion of Control ist besonders in der Programmiersprache Java verbreitet.": Aus dem gleichen Grund irrefuehrend. Die Syntax von Java weiss nichts ueber IoC.

den ersten bemängelten ansatz habe ich gelöscht, er sagt imho nichts aus, was nicht entweder falsch oder redundant wäre. dem zweiten habe ich den ersten satz genommen, der war tatsächlich irreführend. so [1] besser? -- ∂ 10:57, 8. Jul. 2008 (CEST)

„Objektnetzen“?

Siehe Absatz 4, bitte um Definition.