© iStockphoto.com/P2007, © S&S Media
Olis bunte Welt der IT

Kontexte in funktionalem JavaScript


Die Grundidee der funktionalen Programmierung ist, dass Funktionen die Bausteine darstellen, aus denen größere Konstrukte zusammengesetzt werden. Dieser Ansatz ist für verschiedene Programmierer von unterschiedlich großer Bedeutung, denn funktionale Ideen werden in modernen Programmiersprachen oft nur selektiv eingesetzt. Zum Beispiel können Sie in C# auch mal „ein bisschen LINQ machen“, während der Rest des Programms eher objektorientiert implementiert ist. In C# ist es generell schwer, durchweg funktional zu arbeiten, weil die Syntax der Sprache nicht immer gut dafür geeignet ist. In F# ist das etwas einfacher, obwohl die CLR eigentlich objektorientiert ist. Mischansätze sind jedenfalls sehr verbreitet und dabei werden oft Funktionen letztlich nicht als Hauptbausteine größerer Strukturen eingesetzt.

Wenn ich aber nun genau das gern tun möchte, dann ergeben sich daraus neue Herausforderungen. Das sind manchmal dieselben, die in objektorientierten Umgebungen auch existieren, aber die Lösungen fallen anders aus. Die Herausforderung, von der ich hier im Detail schreiben möchte, ist die, Funktionen jeweils mit dem richtigen Ausführungskontext zu versehen, in dem sie ihre Arbeit erledigen können.

Brauchen pure Funktionen Kontext?

Wenn Sie schon einmal funktional programmiert haben, reagieren Sie womöglich erstaunt auf diese Ankündigung. Kontext? Sollen Funktionen im funktionalen Bereich nicht „pur“ sein? Arbeit allein mit Übergabeparametern, keine Nebeneffekte usw., die pure Funktion, die nie außerhalb des eigenen Bereichs schreibend zugreift? Das ist alles richtig, aber gerade in der präzisen Beschreibung findet sich auch das Problem. Wenn wir davon ausgehen, dass die pure Funktion allein mit ihren Übergabeparametern arbeiten darf, wird manch praktische Anforderung schwierig. Wie greift so eine Funktion auf anwendungsweite Zustandsinformationen zu? Wie ruft sie Funktionen aus anderen Modulen auf, wenn diese dynamisch geladen oder konfiguriert werden? Diese Probleme lassen sich am besten anhand von Beispielen belegen. Stellen Sie sich eine einfache Funktion vor. Was sie tut, ist eigentlich egal – daher nehmen wir zunächst ein wirklich einfaches Beispiel:

function mult(x, y) { return x * y; }

Offensichtlich ist diese Funktion „pur“. Sie erhält zwei Parameter und gibt einen Wert zurück, der allein anhand dieser Werte berechnet wird. So stellt man sich das im funktionalen Umfeld vor. Was wäre aber, wenn die Funktion über ihre Arbeit Rechenschaft ablegen soll?

function mult(x, y) { const result = x * y; console.log('mult: ${x} * ${y} = ${result}'); return result; }

Nun ist die Funktion genau genommen nicht mehr pur. Sie hat einen Nebeneffekt: die Daten aus der Funktion werden an einen anderen Ort geschickt, es kommt nichts zurück und dieser Schritt hat auch nichts mit der Berechnungslogik in der Funktion selbst zu tun. Allerdings will ich diese Tatsache hier nicht viel näher beleuchten, denn diese Art von Nebeneffekt ist letztlich unvermeidlich. Wenn Informationen ausgegeben oder etwa Daten gespeichert werden sollen, müssen Nebeneffekte ausgelöst werden. „Echte“ funktionale Umgebungen und Programmiersprachen haben zur Handhabung solcher Nebeneffekte bestimmte Konzepte, wie etwa Monads – das ist allerdings ein Thema für einen anderen Artikel.

Jetzt und hier stellt sich eine andere Frage: Ist es okay für die Funktion, einfach so console.log aufzurufen? Die Antwort ist: v...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang