Funktionale Muster, Rekursion und Lazy Evaluation

JavaScript — Funktionale Muster

0:00 Im letzten Modul haben Sie gelernt, dass Funktionen Werte sind. Das klingt nach einer akademischen Feinheit — hier sehen Sie, was praktisch daraus folgt. Wer diese Eigenschaft nutzt, schreibt keine Schleifenrümpfe mehr, sondern Verarbeitungsketten, die man lesen kann wie einen Satz. Filtere die aktiven, nimm die Namen, gib die ersten zwei zurück. Das ist ein kürzeres Modul als das vorige, aber inhaltlich dicht.

0:25 Und es ist das Modul, in dem sich alles auszahlt, was Sie über Funktionen, Callbacks und Closures gelernt haben.

Funktionen im Einsatz

0:32 Vier Kapitel. Zuerst die Array-Methoden — sieben davon, und die Kunst besteht darin, die zu wählen, die Ihre Frage am direktesten ausdrückt. Dann Funktionen höherer Ordnung, ein Begriff, hinter dem etwas steckt, das Sie längst benutzen. Danach die Rekursion, also Funktionen, die sich selbst aufrufen — mit einem Satz, der unbedingt hängen bleiben muss.

0:53 Und zum Schluss die Verarbeitungsketten in beiden Geschmacksrichtungen, eifrig und träge, mit einer klaren Empfehlung, wann welche passt.

Arrays mit Funktionen durchlaufen

1:02 Beginnen wir mit den Methoden, die Sie täglich benutzen werden. Es sind sieben, und alle machen im Grunde dasselbe: Sie rufen eine Funktion für jeden Eintrag auf. Der Unterschied liegt in der Frage, die sie beantworten — und genau daran wählen Sie aus. Der Mechanismus ist bei allen gleich: Sie übergeben eine Funktion, den Callback, und die Methode ruft sie für jeden Eintrag auf.

1:25 Der zweite Satz enthält das Auswahlkriterium, und das ist der eigentliche Inhalt dieses Kapitels. Welche Methode passt, entscheidet sich an der Frage, die Sie stellen — nicht an der Schleife, die Sie sonst geschrieben hätten. Das ist ein Perspektivwechsel. Statt zu überlegen, wie man durch die Liste läuft, überlegen Sie, was Sie wissen wollen.

1:44 Und die Methode, die Sie wählen, verrät dem Leser diese Absicht, ohne dass er den Rumpf lesen muss. Lesen Sie die rechte Spalte einmal als Liste von Fragen — genau so sollten Sie die Auswahl treffen. Tue etwas mit jedem, ohne Ergebnis. Ein Ergebniswert je Eintrag. Alle, auf die etwas zutrifft. Der erste Treffer. Mindestens einer? Alle? Und ganz unten die Zusammenfassung zu einem einzigen Wert.

2:09 Der Fußtext verdient Beachtung: Die Reduzier-Methode ist mächtig und wird schnell unlesbar. Sie kann alles, was die anderen können — aber wenn eine spezialisierte Methode passt, ist sie die bessere Wahl, weil ihr Name die Absicht schon verrät. Sechs Zeilen, sechs verschiedene Fragen an denselben Bestand — und achten Sie vor allem auf die Rückgabewerte, denn sie unterscheiden sich stark.

2:34 Die ersten beiden liefern Arrays, die dritte ein einzelnes Objekt oder undefined, die nächsten beiden schlicht wahr oder falsch. Und die letzte liefert eine Zahl. Wer diese Unterschiede im Kopf hat, wählt automatisch richtig. Ein Detail zur letzten Zeile: Die Null am Ende ist der Startwert, und den zu vergessen ist eine klassische Fehlerquelle — ohne ihn nimmt die Methode den ersten Eintrag als Start, was bei Objekten in einem Datensalat endet.

3:00 Beantworten Sie vier Fragen an denselben Bestand, jede mit einer passenden Methode — und keine davon mit einer selbst geschriebenen Schleife. Diese Einschränkung ist der Trainingseffekt: Sie zwingt Sie, für jede Frage die passende Methode zu suchen, statt in die vertraute Schleife zu fallen. Der Hinweis nennt das häufigste Beispiel: Fragen der Form „gibt es mindestens ein" führen zur Existenzprüfung, nicht zum Filtern mit anschließender Längenprüfung.

3:25 Beides liefert dasselbe Ergebnis; nur eines sagt, was gemeint war — und hört beim ersten Treffer auf zu suchen. Von der Durchlauf-Methode ein Ergebnis-Array zu erwarten, ist der häufigste Anfängerfehler — sie liefert keines, sie tut nur etwas. Wer ein Ergebnis will, braucht die Umwandlungs-Methode. Der zweite Punkt ist die eben erwähnte Umständlichkeit: filtern und dann die Länge prüfen, wo eine direkte Existenzfrage gemeint war.

3:50 Der dritte ist gefährlich, weil er erst später knallt: Die Suchmethode liefert undefined, wenn nichts passt, und wer darauf zugreift, bekommt einen Fehler an ganz anderer Stelle. Und der letzte ist die Empfehlung aus der Tabelle — die Reduzier-Methode nur dort, wo keine spezialisiertere passt.

Funktionen höherer Ordnung

4:08 Jetzt ein Begriff, der beeindruckender klingt, als er ist. Sie benutzen diese Dinge seit Modul sechs, ohne dass sie einen Namen hatten. Wir geben ihnen jetzt einen — und schauen uns die zweite, seltener genutzte Hälfte davon an. Die Definition ist erfreulich mechanisch: Eine Funktion höherer Ordnung nimmt eine Funktion entgegen, gibt eine zurück, oder beides.

4:30 Und der zweite Satz nimmt dem Begriff die Aura — die Array-Methoden, die wir gerade behandelt haben, sind genau das. Sie nehmen einen Callback entgegen, also eine Funktion. Sie haben also längst mit Funktionen höherer Ordnung gearbeitet. Neu ist die andere Richtung: eine Funktion, die eine Funktion zurückgibt. Das haben wir am Ende des letzten Moduls bei den Closures gesehen, und es ist die Hälfte, aus der die interessanteren Muster entstehen.

4:57 Schauen Sie sich die Berichtsfunktion an: Sie weiß, wie man über eine Liste läuft und etwas ausgibt — aber sie weiß nicht, wie formatiert wird. Das kommt von außen. Zwei Aufrufe darunter, zwei völlig verschiedene Ausgaben, ohne dass die Funktion angefasst wurde. Das ist der Kerngedanke: Die Struktur bleibt, das Verhalten wird übergeben.

5:16 Ohne dieses Muster hätten Sie zwei fast identische Funktionen mit einer unterschiedlichen Zeile — oder eine Funktion mit einem Schalter-Parameter, der von Fall zu Fall wächst. Die Suchfunktion unten zeigt dasselbe Prinzip mit einer Bedingung statt einer Formatierung. Und hier die andere Richtung, die direkt an das Closure-Beispiel aus Modul acht anknüpft.

5:37 Eine Vorlage, aus der zwei Prüffunktionen entstehen — jede mit ihrer eigenen gemerkten Art. Und weil diese Prüfungen ganz normale Werte sind, gehen sie direkt an die Filtermethode. Beachten Sie, wie sich die letzten beiden Zeilen lesen: Filtere die Kräuter, filtere das Obst. Der Code sagt, was er tut. Die Alternative wäre gewesen, den Vergleich zweimal hinzuschreiben — was bei zwei Arten harmlos ist und bei zwanzig zur Fleißarbeit wird, mit einer Kopie, die irgendwann einen Tippfehler enthält.

6:08 Erzeugen Sie drei verschiedene Prüfungen aus einer einzigen Vorlage, und lassen Sie jede die richtigen Treffer liefern. Der Hinweis ist wichtiger, als er aussieht: Übergeben Sie die erzeugte Funktion direkt an die Filtermethode. Sie ist ein ganz normaler Wert und muss nicht in einer Variablen zwischengelagert werden — obwohl das für die Lesbarkeit oft hilft.

6:28 Der Lerneffekt liegt darin, Funktionen so selbstverständlich herumzureichen wie Zahlen. Wenn das erst einmal natürlich wirkt, haben Sie den Kern des funktionalen Arbeitens verstanden. Die zurückgegebene Funktion sofort aufzurufen, statt sie weiterzugeben, ist die Klammer-Falle aus dem letzten Modul in neuem Kontext. Der zweite Punkt ist eine echte Verwirrungsquelle: Bei einer Funktion, die eine Funktion zurückgibt, gibt es zwei Parameterlisten — die äußere für die Konfiguration, die innere für die eigentlichen Daten.

6:58 Wer sie verwechselt, bekommt Ergebnisse, die keinen Sinn ergeben. Der dritte ist eine verpasste Gelegenheit: Verhalten fest einzubauen, obwohl man es übergeben könnte. Und der letzte ist die Maßhalte-Warnung — Ketten so tief zu schachteln, dass niemand mehr die Zwischenwerte benennen kann, ist keine Eleganz.

Rekursion

7:16 Jetzt ein Thema, das Anfängern gern Respekt einflößt: Funktionen, die sich selbst aufrufen. Der Trick daran ist überschaubar, und ein einziger Satz entscheidet über Erfolg und Absturz. Den nehme ich vorweg: Ohne Basisfall keine Rekursion. Rekursion liegt vor, wenn eine Funktion sich selbst aufruft. Das klingt zunächst nach einem Zirkelschluss, und genau deshalb braucht sie zwingend zwei Teile.

7:41 Der Basisfall ist die Bedingung, unter der die Funktion aufhört, sich selbst aufzurufen — die Notbremse. Der rekursive Fall macht mit einer kleineren Eingabe weiter. Beides ist unverzichtbar. Denken Sie an eine Matrjoschka: Sie öffnen eine Puppe, finden eine kleinere, öffnen die auch — und irgendwann kommt die massive, die sich nicht mehr öffnen lässt.

8:02 Das ist der Basisfall. Ohne ihn würden Sie ewig weiteröffnen. Vier Zeilen, und beide Teile stecken darin. Die erste Zeile ist der Basisfall: Bei null ist Schluss. Die letzte ist der rekursive Fall, und beachten Sie das entscheidende Detail — die Eingabe wird um eins kleiner. Genau dadurch nähert sich jeder Aufruf dem Basisfall an.

8:23 Der auskommentierte Block darunter zeigt, was passiert, wenn dieser Fortschritt fehlt: Die Funktion ruft sich mit demselben Wert auf, kommt nie beim Basisfall an, und irgendwann meldet die Laufzeitumgebung einen überlaufenen Aufrufstapel. Das ist übrigens einer der wenigen Fehler, bei denen die Meldung tatsächlich sofort verrät, was los ist.

8:43 Hier sehen Sie, wofür Rekursion wirklich gemacht ist: für Daten, die selbst verschachtelt sind. Ein Bereich enthält Teile, und jeder Teil kann wieder Teile enthalten — beliebig tief, ohne dass Sie beim Schreiben wissen, wie tief. Mit einer Schleife wäre das mühsam. Die rekursive Fassung ist vier Zeilen lang. Und das Eleganteste steht im Fußtext: Der Basisfall braucht hier keine eigene Prüfung.

9:07 Hat ein Knoten keine Teile, läuft die Schleife einfach nicht, und der Aufruf endet. Der Tiefenparameter mit seinem Standardwert sorgt nebenbei für die Einrückung — ein hübsches Beispiel dafür, wie Standardwerte den Aufruf vereinfachen. Geben Sie eine dreistufige Struktur vollständig aus, mit korrekter Einrückung — und ohne die Tiefe fest zu verdrahten.

9:28 Genau das ist der Punkt: Ihre Lösung soll auch mit fünf Stufen funktionieren, ohne dass Sie etwas ändern. Der Hinweis ist eine Ermahnung zur Bodenhaftung, die ich unterstreiche: Prüfen Sie zuerst, ob eine Schleife reicht. Bei flachen Listen ist sie klarer, schneller zu lesen und schwerer kaputtzumachen. Rekursion ist ein Werkzeug für verschachtelte Daten, nicht ein Beweis von Können.

9:51 Der vergessene Basisfall lässt den Aufrufstapel überlaufen — unangenehm, aber wenigstens eindeutig. Subtiler ist der zweite Punkt: Ein Basisfall ist da, aber der rekursive Aufruf verkleinert die Eingabe nicht. Der Effekt ist derselbe, die Ursache schwerer zu sehen. Der dritte ist die Angemessenheitsfrage aus der Aufgabe — Rekursion auf flachen Listen ist Selbstzweck.

10:13 Und der letzte ist ein praktischer: Wer die Tiefe nicht mitführt, verliert die Struktur in der Ausgabe. Alles erscheint auf einer Ebene, und der Baum, den man zeigen wollte, sieht aus wie eine Liste.

Träge Verarbeitungsketten

10:26 Zum Abschluss führen wir zusammen, was wir über Ketten wissen — die eifrigen Array-Methoden aus diesem Modul und die trägen Iterator-Helfer aus Modul sieben. Und wir sehen einen Kniff, der beide Varianten deutlich lesbarer macht. Eine Verarbeitungskette reiht Filter- und Umformungsschritte aneinander — filtern, umwandeln, begrenzen. Der Unterschied zwischen den beiden Familien ist der Zeitpunkt der Arbeit.

10:50 Die Array-Methoden sind eifrig: Jeder Schritt baut sofort eine komplette Zwischenliste, bevor der nächste beginnt. Die Iterator-Helfer sind träge: Sie erzeugen jeden Wert erst, wenn er angefordert wird, und nur so viele, wie gebraucht werden. Beide Ansätze sind legitim, und die Entscheidung zwischen ihnen ist keine Glaubensfrage, sondern eine Frage der Datenmenge — dazu gleich mehr.

11:13 Der Kniff steht in den ersten drei Zeilen: Statt die Bedingungen direkt in die Kette zu schreiben, bekommen sie Namen. Und plötzlich lesen sich beide Ketten darunter fast wie deutsche Sätze — filtere die aktiven, filtere die Kräuter, hole die Namen. Beachten Sie die Namenskonvention: Prüfungen beginnen mit „ist", wertliefernde Funktionen mit „hole". Der Name verrät damit schon den Rückgabetyp.

11:36 Ein zweiter Vorteil ist weniger offensichtlich, aber gewichtiger: Diese kleinen Funktionen lassen sich einzeln aufrufen und einzeln testen. Eine inline geschriebene Bedingung können Sie nicht testen, ohne die ganze Kette auszuführen. Die Empfehlung ist unaufgeregt und geht gegen den Reiz des Neueren. Bei kleinen Listen entscheidet Lesbarkeit, nicht Geschwindigkeit — und dafür sind die vertrauten Array-Methoden meist die klarere Wahl.

12:02 Träge Ketten lohnen sich, wenn die Datenmenge groß ist oder wenn Sie ohnehin nur einen Teil brauchen. Das ist eine Entscheidung, die Sie an Ihren Daten treffen, nicht an der Sprache. Und der vierte Punkt gilt für beide gleichermaßen: Benannte kleine Funktionen machen jede Variante prüfbar und wiederverwendbar. Der Kniff aus der letzten Folie ist also unabhängig davon, für welche Kette Sie sich entscheiden.

12:25 Bauen Sie eine Kette aus mindestens drei benannten Funktionen — und weisen Sie nach, dass sich jede einzeln aufrufen und prüfen lässt. Dieser Nachweis ist die eigentliche Aufgabe, denn er zeigt den Unterschied zur inline geschriebenen Variante. Halten Sie sich dabei an die Namenskonvention aus dem Hinweis: Prüfungen mit „ist", wertliefernde Funktionen mit „hole".

12:47 Das wirkt kleinlich, zahlt sich aber aus, sobald mehrere Leute an einer Codebasis arbeiten. Ein Name, der den Rückgabetyp verrät, erspart einen Blick in die Funktion. Alle Schritte inline zu schreiben, macht die Kette unprüfbar — der Gegenpol zu allem, was wir gerade besprochen haben. Der zweite Punkt ist die Verhältnismäßigkeit: Eine träge Kette für fünf Einträge ist Aufwand ohne Ertrag.

13:11 Der dritte ist der bekannte vergessene Sammel-Aufruf, und er wird besonders unangenehm, wenn Sie den Iterator weitergeben statt einer Liste — dann taucht das Problem erst weiter unten im Programm auf. Und der letzte ist die Namensfrage: Ein Name, der den Rückgabetyp offen lässt, zwingt jeden Leser dazu, in die Funktion hineinzuschauen.

Funktionen tragen die Verarbeitung

13:31 Drei Sätze zum Mitnehmen. Erstens die Auswahlregel bei den Array-Methoden: Die Methode soll die fachliche Frage abbilden, nicht nur das Ergebnis liefern — der Leser soll die Absicht am Namen erkennen. Zweitens: Funktionen höherer Ordnung reichen Verhalten hinein oder geben es zurück, und beide Richtungen ersparen Ihnen kopierten Code.

13:50 Drittens die Regel, die über Erfolg und Absturz entscheidet: Rekursion braucht immer einen Basisfall mit echtem Fortschritt. Im nächsten Modul wird es handwerklich — es geht um Problemlösung und Debugging.