Der Entwickler- Almanach

Integrationen sind abhängig von anderen Funktionseinheiten – doch diese Abhängigkeit ist minimal. Denn
zwar interessiert sich eine Integration für die Semantik einer integrierten Funktionseinheit, sie tut mit deren
Ergebnissen jedoch selbst nichts. Integrationen enthalten keine Logik, das heißt sie sind frei von
Kontrollstrukturen und Ausdrücken. Ihr Job ist allein die Verdrahtung der Blasen, die sie integrieren
sollen. Im einfachsten Fall bestehen sie also nur aus Funktionsaufrufen.
Beispiel:
Das IOSP macht Integrationen einfach zu lesen und robust. Änderungen ergeben sich häufig in der Logik
– doch die ist in den Operationen konzentriert.
Dadurch, dass Integrationen ohne Logik sind, lassen sie sich auch leicht wiederverwenden.
Integrationshierarchien sind deshalb billig. Und das bedeutet, es ist billig, Inkremente im Code zu erhalten.
Für Integrationen muss kein optimales Klassenmodell gefunden werden. Sie selbst greifen ja nicht auf
globale Daten zu. Das tun ausschließlich Operationen. Eine Klasse, die nur Integrationsmethoden enthält,
die für sich jeweils überschaubar sind, kann also durchaus sehr umfangreich sein.
Sie ist in ihrer Struktur trivial. Ein großer Fan-out an Abhängigkeiten von Operationen ist unkritisch, da
die Integration einem anderen Aspekt angehört. Sie ist zu vergleichen mit einem Dependency-Injection-
Container, der ja auch viele Klassen kennt und trotzdem unempfindlich gegen Veränderungen in ihnen ist.
Um die Entkopplung zur Erhaltung der Inkremente noch zu erhöhen, ist allerdings ein weiteres Prinzip
nötig, denke ich. Das nenne ich das Prinzip der gegenseitigen Nichtbeachtung (Principle of Mutual