„Inversion of Control“ – Versionsunterschied
| [gesichtete Version] | [gesichtete Version] |
Keine Bearbeitungszusammenfassung |
D (Diskussion | Beiträge) siehe diskussion |
||
| Zeile 3: | Zeile 3: | ||
Dieses [[Paradigma]] beschreibt die Arbeitsweise von [[Programmiergerüst]]en oder Frameworks: eine [[Funktion (Programmierung)|Funktion]] eines [[Anwendungsprogramm]]s wird bei einer [[Programmbibliothek|Standardbibliothek]] registriert und von dieser zu einem späteren Zeitpunkt aufgerufen. Das wird manchmal als eine Anwendung des „Hollywood-Prinzips“ bezeichnet: ''"don't call us, we'll call you"'' (zu deutsch: „Rufen Sie uns nicht an, wir werden Sie anrufen“): Statt dass die Anwendung den [[Kontrollfluss]] steuert und lediglich Standardfunktionen benutzt, wird die Steuerung der Ausführung bestimmter [[Unterprogramm]]e an das Framework abgegeben. |
Dieses [[Paradigma]] beschreibt die Arbeitsweise von [[Programmiergerüst]]en oder Frameworks: eine [[Funktion (Programmierung)|Funktion]] eines [[Anwendungsprogramm]]s wird bei einer [[Programmbibliothek|Standardbibliothek]] registriert und von dieser zu einem späteren Zeitpunkt aufgerufen. Das wird manchmal als eine Anwendung des „Hollywood-Prinzips“ bezeichnet: ''"don't call us, we'll call you"'' (zu deutsch: „Rufen Sie uns nicht an, wir werden Sie anrufen“): Statt dass die Anwendung den [[Kontrollfluss]] steuert und lediglich Standardfunktionen benutzt, wird die Steuerung der Ausführung bestimmter [[Unterprogramm]]e an das Framework abgegeben. |
||
| ⚫ | Ein einfaches Beispiel einer solchen Umkehrung sind ''[[Listener]]'' (gemäß dem [[Beobachter (Entwurfsmuster)|Beobachter-Muster]]), aber auch [[Applet]]s und [[Servlet]]s folgen diesem Entwurfsmuster. [[Plugin]]s und [[Rückruffunktion]]en sind weitere Beispiele dafür, die Steuerung einzelner Programmteile einem Framework zu überlassen. |
||
Somit funktionieren fast alle modernen Programmiersprachen nach dem Prinzip ''Inversion of Control'': Ein vordefiniertes Framework bildet das Hauptprogramm. Der Programmierer, der eine neue Anwendung auf Basis des Frameworks bzw. der Bibliothek erstellen möchte, hat keinen oder nur wenig Einfluss auf die Steuerung dieses Hauptprogramms. Er kann nur bestimmte [[Funktion (Programmierung)|Funktionen]] implementieren. Diese werden dann durch das Framework aufgerufen. Dies steht im Gegensatz zum klassischen Programmieransatz, bei dem der Programmierer das Hauptprogramm selber schreibt und einzelne Funktionen aufruft, die aus einer Bibliothek stammen. Im klassischen Ansatz ist die Kontrolle hauptsächlich in dem vom Programmierer erstellten Programm. Diese wird kurzzeitig an andere vordefinierte Funktionen abgegeben. Bei ''Inversion of Control'' liegt die Kontrolle hauptsächlich im Framework, welches dann eine Funktion des Programmierers aufruft und somit kurzzeitig die Kontrolle an diese abgibt. |
|||
| ⚫ | |||
Häufig ist auch bei Bibliotheken, die mit ''[[Dependency Injection]]'' arbeiten (wie z. B. [[EJB-Container]] oder das [[Spring (Framework)]]), von ''Inversion of Control'' zu lesen. Hier geht es aber vorwiegend um die Erzeugung von Objektnetzen (''siehe auch:'' [[Fabrikmethode]], [[Komponentenmodell]]). |
Häufig ist auch bei Bibliotheken, die mit ''[[Dependency Injection]]'' arbeiten (wie z. B. [[EJB-Container]] oder das [[Spring (Framework)]]), von ''Inversion of Control'' zu lesen. Hier geht es aber vorwiegend um die Erzeugung von Objektnetzen (''siehe auch:'' [[Fabrikmethode]], [[Komponentenmodell]]). |
||
Version vom 8. Juli 2008, 10:55 Uhr
Der Begriff Inversion of Control (IOC; deutsch: „Umkehrung der Steuerung“ oder „Steuerungsumkehr“) bezeichnet ein Umsetzungsparadigma, das in der objektorientierten Programmierung Anwendung findet.
Dieses Paradigma beschreibt die Arbeitsweise von Programmiergerüsten oder Frameworks: eine Funktion eines Anwendungsprogramms wird bei einer Standardbibliothek registriert und von dieser zu einem späteren Zeitpunkt aufgerufen. Das wird manchmal als eine Anwendung des „Hollywood-Prinzips“ bezeichnet: "don't call us, we'll call you" (zu deutsch: „Rufen Sie uns nicht an, wir werden Sie anrufen“): Statt dass die Anwendung den Kontrollfluss steuert und lediglich Standardfunktionen benutzt, wird die Steuerung der Ausführung bestimmter Unterprogramme an das Framework abgegeben.
Ein einfaches Beispiel einer solchen Umkehrung sind Listener (gemäß dem Beobachter-Muster), aber auch Applets und Servlets folgen diesem Entwurfsmuster. Plugins und Rückruffunktionen sind weitere Beispiele dafür, die Steuerung einzelner Programmteile einem Framework zu überlassen.
Häufig ist auch bei Bibliotheken, die mit Dependency Injection arbeiten (wie z. B. EJB-Container oder das Spring (Framework)), von Inversion of Control zu lesen. Hier geht es aber vorwiegend um die Erzeugung von Objektnetzen (siehe auch: Fabrikmethode, Komponentenmodell).