12.7    Was ist jetzt so funktional? 

Bisher wurde ein Großteil dieses Abschnitts darauf verwendet, die Typen aus dem java.util.function-Paket vorzustellen, also die funktionalen Schnittstellen, mit denen Entwickler Abbildungen in Java ausdrücken können. Sprechen wir nun allgemeiner von der funktionalen Programmierung und ihren Vorteilen.

Wiederverwertbarkeit

Zunächst einmal bieten Funktionen eine zusätzliche Ebene der Wiederverwertbarkeit von Code. Nehmen wir ein Prädikat wie:

Predicate<Path> exists = path -> Files.exists( path );

Dieses exists-Prädikat ist relativ einfach und lässt auch noch die Ausnahmebehandlung aus. Es könnte aber natürlich komplexer sein. Der Punkt ist, dass diese Prädikate an allen möglichen Stellen wiederverwendet werden können, etwa zum Filtern in Listen oder zum Löschen von Elementen aus Listen. Das Prädikat kann als Funktion weitergereicht oder zu neuen Prädikaten verbunden werden, etwa zu:

Predicate<Path> exists    = path -> Files.exists( path );

Predicate<Path> directory = path -> Files.isDirectory( path );

Predicate<Path> existsAndDirectory = exists.and( directory );

Methoden wie ifPresent(Predicate) oder removeIf(Predicate) nehmen dann dieses Prädikat und führen Operationen durch. Diese kleinen Mini-Objekte lassen sich sehr gut testen, und das minimiert insgesamt Fehler im Code.

Während aktuelle Bibliotheken wenig davon Gebrauch machen, Typen wie Supplier, Consumer, Function oder Predicate anzunehmen und zurückzugeben, wird sich dieses im Laufe der nächsten Jahre ändern.

Zustandslos, immutable

Bei der funktionalen Programmierung geht es darum, ohne externe Zustände auszukommen. Pure funktionale Programmiersprachen basieren auf puren Funktionen, und auch in Java muss nicht jede Methode einen äußeren Zustand verändern. Allerdings sind es Java-Entwickler gewohnt, in Zuständen zu denken, und daran ist an sich nichts Falsches: Ein Textdokument im Speicher ist eben ein Objektgraph genauso wie eine grafische Anwendung mit Eingabefeldern. Worauf funktionale Programmierung abzielt, sind die Operationen auf den Datenstrukturen und Berechnungen, die ohne Seiteneffekte sind.

Pure Funktionen ohne Zustand haben den Vorteil, dass sie

• beliebig oft ausgeführt werden können, ohne dass sich Systemzustände ändern,

• in beliebiger Reihenfolge ausgeführt werden können, ohne dass das Ergebnis ein anderes wird und

• einfacher zu testen sind, als wenn es umfangreiche Zustandsänderungen gibt.

Diese Vorteile sind reizvoll unter dem Gesichtspunkt der Parallelisierung, denn die Prozessoren werden nicht wirklich schneller, aber wir haben mehr Prozessorkerne zur Verfügung. Pure Funktionen erlauben es Bibliotheken, Aufgaben wie Suchen und Filtern auf Kerne zu verteilen und auf diese Weise zu parallelisieren. Je weniger Zustand dabei im Spiel ist, desto besser, denn je weniger Zustand, desto weniger Synchronisation und Warteeffekte gibt es.

Aufpassen müssen Entwickler natürlich trotzdem, denn ein Lambda-Ausdruck muss nicht pur sein und kann Seiteneffekte haben. Daher ist es wichtig zu wissen, wann diese Lambda-Ausdrücke vielleicht nebenläufig sind und eine Synchronisation nötig ist.

List<Integer> ints = new ArrayList<>( Arrays.asList( 1, 99, 2 ) );

ints.forEach( v -> { System.out.println( ints + ", " + v); ints.set( v, 0 ); } );

[1, 99, 2], 1

[1, 0, 2], 0

[0, 0, 2], 2

Die Vermeidung von Zuständen, gekoppelt an die Unveränderbarkeit von Werten (engl. immutability), erhöht das Verständnis des Programms, da Entwickler es schwer haben, im Kopf das System mit den ganzen Änderungen »nachzuspielen«, insbesondere wenn diese Änderungen noch nebenläufig sind. Das zeigt das vorangehende Beispiel recht gut. Solche Systeme zu verstehen und zu debuggen ist schwer. Je weniger Seiteneffekte es gibt, desto einfacher ist das Programm zu verstehen. Zustände machen ein Programm komplex, nicht nur in nebenläufigen Umgebungen. Wenn die Methode pur ist, muss ein Entwickler nichts anderes tun, als den Code der Methode zu verstehen. Wenn die Methode von Zuständen des Objekts abhängt, muss ein Entwickler den Code der gesamten Klasse verstehen. Und wenn das Objekt von Zuständen im Gesamtprogramm abhängt, ufert das Ganze aus, denn dann muss man noch viel mehr vom System verstehen.