Der Entwickler- Almanach

Oblivion [PoMO]). Das bedeutet: Es gibt keine funktionalen Abhängigkeiten zwischen Blasen auf
derselben Ebene. Insbesondere beachten Operationen einander nicht.
Funktional ist eine Abhängigkeit, wenn Funktionseinheit C wie Client die Funktionseinheit S wie Service
braucht, um an sie Arbeiten zu delegieren, mit deren Resultaten sie selbst dann weiterarbeitet.
Weiterarbeiten bedeutet, die Resultate in eigener Logik zu verwenden.
Solche Abhängigkeiten sind in der üblichen prozeduralen, objektorientierten und auch funktionalen
Programmierung gang und gäbe. Das macht es so schwer, Abhängigkeitsverhaue zu verändern. Und es
leidet die Wiederverwendbarkeit. Auch die Composability wird schwierig, weil immer und überall
Abhängigkeitsbeziehungen befriedigt werden müssen. Inversion of Control und Dependency Injection
mögen da helfen – sie reduzieren die Zahl der funktionalen Abhängigkeiten jedoch nicht.
Deshalb glaube ich, dass echt agiler Entwurf noch einen Schritt weiter gehen muss. Es muss Kopplung
abschütteln, wo es geht. Das IOSP ist ein Anfang. Doch dazu muss noch das PoMO treten. Operationen
und ihre Klassen müssen so definiert werden, dass sie unabhängig voneinander sind. Dann werden
nämlich die Klassenhierarchien so einfach, wie Abbildung 13 das für das Beispielszenario vormacht.
Darüber hinaus gibt es zwar noch Abhängigkeiten von gemeinsamen Daten – hier wäre zum Beispiel ein
Datentyp für eine Seite zu nennen, der Überschrift und Datenzeilen transportiert –, doch die sind ebenfalls
unkritisch.
Das ist wahrscheinlich fern Ihrer gewohnten Objektorientierung, die erstens darauf abzielt, Daten und
Funktionalität zusammenzulegen und zweitens gern funktionale Kollaborationen zwischen Klassen
herstellt. Doch es ist nicht per se gegen die Objektorientierung gerichtet. Klassen/Objekte haben auch nach
dem agilen Entwurf ihre Berechtigung.
Wenn man den Entwurf des Beispielszenarios weitertreibt, dann bekommen zum Beispiel
Ressourcenzugriff oder Blättern ganz natürlich einen Zustand. Mit dem umzugehen, ist mittels
objektorientierter Mittel einfacher als bei einer puren funktionalen Programmierung.
Es geht bei der Beschreibung eines agilen Entwurfs nicht gegen die Objektorientierung, sondern um einen
Rahmen für sie. Sie soll eingepasst werden, um vom Impedanzunterschied zwischen agilem Vorgehen und
Codierung wegzukommen. Klassen sind ein wunderbares Abstraktionsmittel. Doch Abstraktion bedeutet,
dass es schon ein Muster gibt, das erkannt und mit einer Klasse ausgedrückt werden kann. Das geschieht
beim agilen Entwurf ganz natürlich. Da sind zuerst Interaktionen und Features beziehungsweise
Integrationen und Operationen. Und darin finden sich Gruppen von Funktionseinheiten, die enger
zusammengehören.
Anders beim Vorgehen in objektorientierter Manier mit Class-Responsibility- Collaboration-Kärtchen [9]:
Dort stehen Klassen im Vordergrund und man muss sich mühen, Verantwortlichkeiten darauf zu verteilen.
Solcher gespielter Entwurf ist nicht getrieben durch Inkremente, sondern durch technische Belange oder
eine animistische Sicht, die Software als Gemeinschaft belebter Objekte sieht. Kein Wunder, dass das
Ermahnungen zur Folge hat, Klassen nicht Controller, Manager oder Coordinator zu nennen.
Wie Abbildung 13 zeigt, ist das für agilen Entwurf kein Thema. Klassen entstanden durch Abstraktion von
Funktionseinheiten und bekommen intuitiv andere Namen, die näher an der Domäne sind.
Das übliche objektorientierte Vorgehen, welches zuerst Klassen findet und dann Methoden, ist insofern
eine vorzeitige Optimierung. Hierarchien müssen von unten wachsen (bottom-up), sonst fehlt höheren
Hierarchieebenen die Legitimation.
Ein Dirigent ist kein Selbstzweck, sondern deckt einen Bedarf an Koordination, wenn eine Gruppe von
Musikern eine bestimmte Größe erreicht hat. Genauso ist eine Klasse kein Selbstzweck, sondern es muss
einen Bedarf für sie geben. Der jedoch entsteht erst, wenn es eine Gruppe von Funktionen gibt, die davon
profitieren, zusammengefasst zu werden.