Zum Inhalt springen
iSAQB Blog Functional Architecture Is Better

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!

Teilen Sie diesen Artikel:

Über die Autor:innen

Dr. Michael Sperber
Organisation
Active Group GmbH
Land
Deutschland
Michael Sperber ist Geschäftsführer der Active Group in Tübingen, die Softwareprojektentwicklung mittels funktionaler Programmierung betreibt. Mike entwickelt seit 1984 Software und ist anerkannter Experte für funktionale Programmierung, die er seit mehr als 25 Jahren in Forschung, Lehre und industrieller Entwicklung anwendet. Er ist Autor zahlreicher wissenschaftlicher Arbeiten, Artikel und Bücher zu diesem Thema, darunter des iSAQB-Lehrplans zur funktionalen Softwarearchitektur. Mike ist Mitbegründer des Blogs funktionale-programmierung.de und Mitorganisator der jährlichen BOB-Entwicklerkonferenz.  

Unsere aktuellsten Blog-Artikel

Bleiben Sie informiert mit dem iSAQB®-Newsletter!

Nach oben scrollen