Funktionale Archi­tektur ist besser

Wittgen­stein schrieb: „Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt.“

Moritz Nähr, Public domain, via Wikimedia Commons

Und funktionale Archi­tektur funktio­niert am besten mit funktio­nalen Programmiersprachen.

Funktionale Software­architektur („FUNAR“) ist eins der fortge­schrit­tensten Curricula im iSAQB-Advanced-Kanon. Es geht um die beson­deren Struk­tu­rie­rungs- und Model­lie­rungs­tech­niken der funktio­nalen Program­mierung. Diese unter­scheiden sich erheblich von den konven­tio­nellen Techniken aus der objekt­ori­en­tierten Archi­tektur und führen zu deutlichen Verbes­se­rungen bei wichtigen Archi­tek­tur­ei­gen­schaften: Kopplung und Komple­xität sind geringer, die Modelle sind geschmei­diger und es ist einfacher, Korrektheit sicherzustellen.

Wie macht die funktionale Archi­tektur das?  Die drei wichtigsten Faktoren dafür sind:

• unver­än­der­liche Daten
• mächtige Abstrak­tionen
• Algebra

Was bedeutet das im Einzelnen?

Unver­än­der­liche Daten bedeutet, dass Objekte nach der Erzeugung nicht noch einmal verändert werden. Es gibt keine „Setter-Methoden“. Das klingt erst einmal nach einer schwer­wie­genden Einschränkung gegenüber OO, weniger wie ein Feature: Die objekt­ori­en­tierten Program­mierung hat die Verän­derung von Objekten schließlich geradezu als Grundlage – und wie will man denn so Zustand modellieren?

Tatsächlich ist das ganz einfach: Wenn in einer funktio­nalen Archi­tektur eine Zustands­än­derung eintritt, wird nicht das „alte“ Zustands­objekt verändert, sondern einfach ein neues erzeugt. Das alte bleibt, wie es ist – sozusagen als Erinnerung an die Vergan­genheit. Objekte, die Zustand reprä­sen­tieren, sind in der funktio­nalen Program­mierung also eine Art „Schnapp­schuss“.

Dass keine Objekte „in situ“ verändert werden, hat viele konkrete Vorteile:

• Die Ausgabe einer Funktion wird nur durch ihre Eingaben bestimmt: Das macht es leichter, ihr Verhalten zu beschreiben und verstärkt die Aussa­ge­kraft von Typsignaturen.
• Solche Funktionen sind viel leichter zu testen als Methoden, die Zustand ändern und womöglich „Setup“ und „Teardown“ benötigen.
• Implizite Abhän­gig­keiten durch globalen Zustand werden reduziert, was zur Reduktion von Kopplung um eine Größen­ordnung führt.
• Funktionen in der Software entsprechen den Funktionen in der Mathe­matik und sind damit mathe­ma­ti­schen Schluss­weisen zugänglich – dazu später noch mehr.
• In neben­läu­figen Programmen muss der Zugriff auf Objekte nicht aufwendig koordi­niert werden.

Wer das erstmal nicht intuitiv findet, ist schnell positiv überrascht, wie einfach das ist und wie viel mehr das der mensch­lichen Wahrnehmung entspricht, Schnapp­schüsse anzufer­tigen als durch Setter-Methoden die Vergan­genheit zu zerstören.

(OO-Experten werden einwenden, dass auch dort bekannt ist, dass „value objects“ – unver­än­der­liche Objekte – eine gute Idee seien. Eben!)

Mächtige Abstrak­tionen bedeutet, dass funktionale Program­mierung höher­ste­hende Abstrak­tionen erlaubt als in OO. Manche dieser Abstrak­tionen haben ihren Weg schon in OO-Sprachen geschafft, wie zum Beispiel die map-Funktion auf Collec­tions. Die sind aber nur die Spitze eines Eisbergs vielerlei Libraries mit abstrakten, aber nützlichen Ideen. Und obwohl OO-Sprachen so mache funktionale Features dazuge­wonnen haben („Lambda“), sind diese doch in der Verwendung gegenüber echten FP-Sprachen einge­schränkt oder umständlich, was dann auch solche Abstrak­tionen weniger nützlich macht.

Überhaupt wird in der funktio­nalen Archi­tektur mehr abstra­hiert, auch und gerade, wenn es um die Model­lierung konkreter Domänen geht. Da funktionale Sprachen uniformer aufgebaut sind als ihre OO-Pendants, ist Abstraktion in funktio­naler Archi­tektur syste­ma­ti­scher und geht nur selten schief.

Diese „syste­ma­tische Abstraktion“ wird zusätzlich unter­stützt durch die Zugäng­lichkeit mathe­ma­ti­scher Konzepte, speziell aus der Algebra: Viele Domänen­mo­delle weisen Eigen­schaften auf, die in der Algebra schon seit Jahrhun­derten katalo­gi­siert und unter­sucht sind. (Mancher scheut den Einsatz von Mathe­matik bei der Software-Entwicklung. Das ist einiger­maßen schade, war es doch das Werkzeug der Menschheit zur formalen Model­lierung unserer Umwelt, bevor es Computer gab, mit entspre­chend viel Erfahrung und zahlreichen Erkennt­nissen.) So liefern algebraische Konzepte wie „Monoid“ oder „Funktor“ häufig neue Domänen­ein­sichten. Die Grenze zu regel­rechten domänen­spe­zi­fi­schen Sprachen ist fließend.

Noch ein weiterer wesent­licher Unter­schied: Funktionale Archi­tektur ist Code; für ihre Konstruktion ist keine weitere Zwischen­no­tation notwendig. Auch dies wird durch die verbes­serte Ausdrucks­kraft funktio­naler Sprachen ermög­licht, welche die „Vogel­per­spektive“ der Archi­tektur direkt sichtbar macht.

Man merkt schon, das ist eine ganz andere Welt, und ziemlich anspruchsvoll für eine dreitägige Schulung. Man sollte (neben Neugier) deshalb schon Vorkennt­nisse in funktio­naler Program­mierung mitbringen.  Aber keine Sorge, offene FUNAR-Schulungen stellen meist einen eintä­gigen Schnell-Vorkurs zur Verfügung, der diese herstellt. Wer sich der Heraus­for­derung stellt, kommt mit vielen Erkennt­nissen zurück, von denen einige auch in der objekt­ori­en­tierten Archi­tektur nützlich sind – zum Beispiel die Model­lierung mit sogenannten combi­nators. Auch eine Brücke zum Domain-Driven Design wird geschlagen, was mit funktio­naler Program­mierung noch besser funktio­niert als mit OO.

Als Belohnung gibt es 10 Credit Points im Kompe­tenz­be­reich Methodik und 20 Credit Points im Kompe­tenz­be­reich Technik. Wir freuen uns auf Sie!