© Excellent backgrounds/Shutterstock.com
Java Magazin
Event-driven Design als architekturaler Denkansatz

Die Lehre der Passivität

In den Anfangszeiten der Informatik folgte alles dem EVA-Pattern. Programme nahmen eine Eingabe entgegen, verarbeiteten sie und gaben die Ergebnisse der Verarbeitung aus. Erst das Aufkommen grafischer Benutzerschnittstellen (und von Visual Basic) brachte Events in den Erlebnishorizont des Durchschnittsprogrammierers.

Tam Hanna


Events sind nicht auf das Erstellen von grafischen Benutzerschnittstellen beschränkt. Im Laufe der letzten Jahre hat sich in den Vereinigten Staaten das Paradigma des eventbasierten Systems etabliert. Dabei handelt es sich um ein Softwaresystem, dessen einzelne Module miteinander über so genannte Notifications kommunizieren. Das bringt – neben diversen anderen Vorteilen – auch den Vorteil der reduzierten Kopplung zwischen den einzelnen Modulen. In kleinen Systemen hat man freilich nicht viel davon, und der durch Frameworks etc. entstandene Aufwand rentiert sich nicht. Bei größeren Systemen lohnt sich die Mühe allerdings schon.

Coupling, was ist das?

Das Konzept des Couplings wurde 1974 in der IT-Welt eingeführt. Damals veröffentlichten drei Forscher ein Paper namens Structure Design, das in der Mai-Ausgabe des IBM Systems Journal veröffentlicht wurde. Sie definierten Coupling (zusammen mit dem Begriff Cohesion) als die Maßeinheit, die die Stärke der Verbindung zwischen den einzelnen Modulen eines Softwaresystems angibt. Der genaue Unterschied der Begriffe ist für unsere erste Betrachtung hier nicht relevant.

Erstellt man ein Programm unter Anwendung objekt­orientierter Designprinzipien, erhält man automatisch ein System, das reich an Coupling, also an Beziehungen untereinander, ist. Denn: Objektorientierte Systeme bestehen aus Klassen, die – miteinander verzahnt – gemeinsam diverse Aufgaben angehen. Dadurch entsteht im Laufe der Zeit ein in den USA als Stovepipe-System bezeichneter Zustand: ein System, in dem die Mehrzahl der Klassen von der Mehrzahl der anderen Klassen abhängig ist.

Wie schon in der Einleitung festgestellt, ist das für kleine und in einer einzelnen Assembly bzw. .jar-Datei enthaltene Systeme kein wirkliches Problem. Kritisch wird Coupling erst dann, wenn ein System über mehrere .jar-Dateien oder gar Anlagen verteilt ist. Hat ein System direkte Abhängigkeiten zwischen allen .jar-Dateien, kann man die einzelnen .jar-Dateien nicht ohne Weiteres recyceln. Das erschwert logischerweise die Wiederverwendung einzelner Komponenten.

Systeme ohne Coupling?

Nach dieser Einleitung scheint es nur logisch, im eigenen System Coupling zu vermeiden. Leider ist das nicht möglich: Stehen die einzelnen Teile eines Systems in keiner Beziehung zueinander, hat man nämlich kein System mehr. Die Lösung besteht darin, die Verknüpfungen zwischen den einzelnen Elementen des Systems aufzubrechen. Unter Umständen führt man dazu sogar neue, Binder genannte, Klassen ein. Au...

Java Magazin
Event-driven Design als architekturaler Denkansatz

Die Lehre der Passivität

In den Anfangszeiten der Informatik folgte alles dem EVA-Pattern. Programme nahmen eine Eingabe entgegen, verarbeiteten sie und gaben die Ergebnisse der Verarbeitung aus. Erst das Aufkommen grafischer Benutzerschnittstellen (und von Visual Basic) brachte Events in den Erlebnishorizont des Durchschnittsprogrammierers.

Tam Hanna


Events sind nicht auf das Erstellen von grafischen Benutzerschnittstellen beschränkt. Im Laufe der letzten Jahre hat sich in den Vereinigten Staaten das Paradigma des eventbasierten Systems etabliert. Dabei handelt es sich um ein Softwaresystem, dessen einzelne Module miteinander über so genannte Notifications kommunizieren. Das bringt – neben diversen anderen Vorteilen – auch den Vorteil der reduzierten Kopplung zwischen den einzelnen Modulen. In kleinen Systemen hat man freilich nicht viel davon, und der durch Frameworks etc. entstandene Aufwand rentiert sich nicht. Bei größeren Systemen lohnt sich die Mühe allerdings schon.

Coupling, was ist das?

Das Konzept des Couplings wurde 1974 in der IT-Welt eingeführt. Damals veröffentlichten drei Forscher ein Paper namens Structure Design, das in der Mai-Ausgabe des IBM Systems Journal veröffentlicht wurde. Sie definierten Coupling (zusammen mit dem Begriff Cohesion) als die Maßeinheit, die die Stärke der Verbindung zwischen den einzelnen Modulen eines Softwaresystems angibt. Der genaue Unterschied der Begriffe ist für unsere erste Betrachtung hier nicht relevant.

Erstellt man ein Programm unter Anwendung objekt­orientierter Designprinzipien, erhält man automatisch ein System, das reich an Coupling, also an Beziehungen untereinander, ist. Denn: Objektorientierte Systeme bestehen aus Klassen, die – miteinander verzahnt – gemeinsam diverse Aufgaben angehen. Dadurch entsteht im Laufe der Zeit ein in den USA als Stovepipe-System bezeichneter Zustand: ein System, in dem die Mehrzahl der Klassen von der Mehrzahl der anderen Klassen abhängig ist.

Wie schon in der Einleitung festgestellt, ist das für kleine und in einer einzelnen Assembly bzw. .jar-Datei enthaltene Systeme kein wirkliches Problem. Kritisch wird Coupling erst dann, wenn ein System über mehrere .jar-Dateien oder gar Anlagen verteilt ist. Hat ein System direkte Abhängigkeiten zwischen allen .jar-Dateien, kann man die einzelnen .jar-Dateien nicht ohne Weiteres recyceln. Das erschwert logischerweise die Wiederverwendung einzelner Komponenten.

Systeme ohne Coupling?

Nach dieser Einleitung scheint es nur logisch, im eigenen System Coupling zu vermeiden. Leider ist das nicht möglich: Stehen die einzelnen Teile eines Systems in keiner Beziehung zueinander, hat man nämlich kein System mehr. Die Lösung besteht darin, die Verknüpfungen zwischen den einzelnen Elementen des Systems aufzubrechen. Unter Umständen führt man dazu sogar neue, Binder genannte, Klassen ein. Au...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang