© StonePictures/Shutterstock.com
Unter dem Druck der Ereignisse - Teil 1

Kopplung und Event-Orientierung


„Wenn die Entwicklung schwierig wird, werden kleinere Schritte probiert.“ Dieser Spruch aus dem Ingenieurroman über die Katastrophen des Dietrich Drahtlos [1] ist in der Softwarebranche seit Jahrzehnten Gang und Gäbe. Über die eigentliche Frage, wie man ein nicht überblickbares Softwaresystem in mundgerechte Elemente unterteilen kann, lässt sich jedenfalls hervorragend streiten. Ein Ansatz ist hier die Event-orientierte Entwicklung, die wir uns in dieser Artikelserie ausführlich ansehen wollen.

Die Event-Orientierung ist ein vergleichsweise wenig diskutiertes Paradigma der Softwareentwicklung. Das könnte an ihrer Einfachheit liegen, die es für akademische Papers wenig nützlich erscheinen lässt. Als .NET-Programmierer sollte man hier eigentlich einen gewissen Startvorteil haben, denn bereits im Jahr 2006 erschien beim damals für .NET-Themen vorgesehenen Apress-Verlag eines der besten Bücher zu diesem Thema: „Event-Based Programming. Taking Events to the Limit“ von Ted Faison [2].

Welche Vorteile die Event-orientierte Programmierung bietet, wie man Event-orientierte Architekturen baut und welche kommerziellen Implementierungsmöglichkeiten es gibt, möchten wir in dieser Artikelserie beleuchten.

Formalisierung durch Kalküle

Sie kennen sicherlich den Kalauer, dass nur das verbesserbar sei, was man auch messen kann. Ist das Ziel der Event-orientierten Programmierung eine Simplifikation des Gesamtsystems, so benötigen wir ein Verfahren zur Messung der Komplexität. Ein Klassiker dazu ist der im ehrwürdigen IBM Systems Journal im Mai 1974 erschienene Beitrag „Structured Design“, der das Konzept des Couplings einführt [3]. Dahinter steht der Gedanke, dass logische Elemente – seien es Funktionen, Klassen oder ganze Threads – irgendwie voneinander abhängig sind.

Es ist unmöglich, ein wirtschaftlich sinnvolles System zu entwerfen, das komplett ohne Couplings auskommt. Daraus folgt, dass eine der Aufgaben der Systemarchitektur darin bestehen muss, Kopplungen zu verwalten. Ein schöner Weg, um sich der Idee der Couplings anzunähern, ist das in der Programmiersprache QML enthaltene Uses-Symbol: Dass eine Kopplung auch eine Nutzung der einzelnen Komponenten darstellt, sollte aus der logischen Konsequenz folgen. Ted Faison stellt nun die Frage, wie das Coupling erfolgt, bzw. wie stark es die Flexibilität des Entwicklers einschränkt.

Der wichtigste Weg zur Unterteilung der Kopplungsarten betrifft statische und dynamische Kopplung. Statische Kopplung ist insofern komplizierter, da sie die Komponente schon zur Kompilationszeit betrifft und somit Kombinationen von unbefriedigten Kopplungsbeziehungen verhindert. Ein schönes Beispiel dafür wäre das in Abbildung 1 gezeigte Beziehungsdiagramm. In diesem greift die Klasse A beispielsweise direkt auf eine in der Klasse B definierte Konstante oder Methode zurück. Das ∝-Symbol ist dabei ein von Ted Faison eingeführtes Zeichen, das Kopplungen beschreibt. Im Laufe der letzten Jahre hat es sich auch abseits seines Klassikers zumindest bis zu einem gewissen Grad etabliert. Zudem taugt es als kleines Werkzeug zur zusätzlichen Formalisierung der Gedanken bei der Event-orientierten Programmierung.

hanna_netevent_1.tif_fmt1.jpgAbb. 1: Statische Kopplung ist einfach, aber auch vergleichsweise destruktiv

An dieser Stelle wollen wir unsere erste Kopplungstransformation ansehen. Abbildung 2 zeigt eine weitere Variante des Systems, in der die Methode in einem Interface deklariert ist. Zur Kompilation ist der Inhalt von C nun nicht mehr relevant, weshalb zwischen A und B nur noch eine statische, zwischen A und C aber nur noch eine dynamische Kopplung besteht.

hanna_netevent_3.tif_fmt1.jpgAbb. 2: Die Kopplungstransformation reduziert die Systemkomplexität

Vom Sinn des Ganzen

Bei nüchterner Betrachtung der in Abbildung 2 gezeigten Klassenhierarchie denkt sich der Entwickler womöglich, man hätte hier nicht viel gewonnen. Da aber die Unterteilung und Entkopplung von Softwaresystemen ebenfalls Vorteile bringt, muss es noch einen anderen Weg zu ihrer Bewertung geben. In der Literatur wird in vielerlei Quellen darüber diskutiert. Der vernünftigste Ansatz stammt abermals von Ted Faison, der die Kopplungsbeziehungsarten in drei Typen unterteilt.

Der am wenigsten wünschenswerte, aber auch am schwierigsten zu fassende Kopplungstyp ist dabei die logische Kopplung. Eine solche Kopplung entsteht immer dann, wenn zwei Klassen davon ausgehen, dass ihr jeweiliger Counterpart eine bestimmte Aufgabe erledigt. Es ist offensichtlich, warum das kritisch ist: Der Compiler hat keine wirkliche Möglichkeit, festzustellen, dass die Methode au...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang