Zum Inhalt
wannacode

Template Method und Iterator

Kurz gesagt: Template Method hält das gemeinsame Gerüst eines Algorithmus in einer Basisklasse, während Unterklassen die Schritte ausfüllen; Iterator gibt Elemente eins nach dem anderen heraus, ohne zu zeigen, wie sie gespeichert sind.

Problem

Zwei Berichte mit demselben Gerüst

Die Buchhaltung will die Bestellungen als CSV, und die Website will dieselben als HTML-Tabelle. Stornierte Bestellungen kommen nicht in den Bericht. Jemand hat den CSV-Bericht geschrieben und dann die Funktion für HTML kopiert:

function exportCsv(orders) {
const lines = ["Bestellung,Summe"];
let total = 0;
for (const order of orders) {
if (order.cancelled) {
continue;
}
lines.push(`${order.id},${order.total.toFixed(2)}`);
total += order.total;
}
lines.push(`gesamt,${total.toFixed(2)}`);
return lines.join("\n");
}
function exportHtml(orders) {
const lines = ["<table>", "<tr><th>Bestellung</th><th>Summe</th></tr>"];
let total = 0;
for (const order of orders) {
lines.push(`<tr><td>${order.id}</td><td>${order.total.toFixed(2)}</td></tr>`);
total += order.total;
}
lines.push(`<tr><td>Gesamt</td><td>${total.toFixed(2)}</td></tr>`);
lines.push("</table>");
return lines.join("\n");
}
const orders = [
{ id: 1001, total: 80, cancelled: false },
{ id: 1002, total: 25.5, cancelled: false },
{ id: 1003, total: 40, cancelled: true },
];
console.log(exportCsv(orders));
console.log(exportHtml(orders));
Ausgabe
Bestellung,Summe
1001,80.00
1002,25.50
gesamt,105.50
<table>
<tr><th>Bestellung</th><th>Summe</th></tr>
<tr><td>1001</td><td>80.00</td></tr>
<tr><td>1002</td><td>25.50</td></tr>
<tr><td>1003</td><td>40.00</td></tr>
<tr><td>Gesamt</td><td>145.50</td></tr>
</table>

Die beiden Berichte zeigen eine unterschiedliche Summe: CSV sagt 105.50 €, und HTML sagt 145.50 €. Die Regel „stornierte Bestellungen zählen nicht“ gibt es nur in der ersten Kopie. Beide Kopien tun dasselbe: Sie öffnen, schreiben eine Kopfzeile, laufen über die Bestellungen, schreiben die Summe und schließen. Nur die Zeilen, die sie schreiben, sind verschieden. Ein drittes Format wird eine dritte Kopie, und die Regel muss an noch einer Stelle im Kopf behalten werden.

Die Idee

Template Method: ein Gerüst, verschiedene Schritte

Was sich nicht ändert, ist die Reihenfolge der Schritte und die Regeln dazwischen: öffnen, Kopfzeile, eine Zeile für jede Bestellung außer den stornierten, Summe, schließen. Was sich ändert, ist, wie jeder Schritt aussieht.

Das Gerüst kommt in die Basisklasse Report, in die Methode export. An jeder Stelle, an der sich die Formate unterscheiden, ruft sie einen Schritt auf: header, row, footer. Die Unterklasse schreibt nur die Schritte. Ein Schritt, der optional ist (open und close, die CSV nicht nutzt), hat in der Basisklasse einen leeren Rumpf und heißt Hook.

Das ist das Muster Template Method. Es hat zwei Rollen:

  • die Basisklasse mit dem Gerüst: Sie bestimmt die Reihenfolge und ruft die Schritte auf;
  • die Unterklassen: CsvReport und HtmlReport schreiben die Schritte und rufen selbst nichts auf.

Sieh es dir an

Das Gerüst und die beiden Berichte

JavaScript hat kein abstract. Ein nötiger Schritt in der Basisklasse wirft einen Fehler, wenn die Unterklasse ihn nicht geschrieben hat. Die beiden Hooks sind leer:
class Report {
export(orders) {
const lines = [];
this.open(lines);
this.header(lines);
let total = 0;
for (const order of orders) {
if (order.cancelled) {
continue;
}
this.row(lines, order);
total += order.total;
}
this.footer(lines, total);
this.close(lines);
return lines.join("\n");
}
open(lines) {}
header(lines) {
throw new Error("header() muss geschrieben werden");
}
row(lines, order) {
throw new Error("row() muss geschrieben werden");
}
footer(lines, total) {
throw new Error("footer() muss geschrieben werden");
}
close(lines) {}
}

Die beiden Berichte schreiben nur ihre Zeilen. CsvReport schreibt die Hooks nicht und nutzt deshalb die leeren aus der Basisklasse:

class CsvReport extends Report {
header(lines) {
lines.push("Bestellung,Summe");
}
row(lines, order) {
lines.push(`${order.id},${order.total.toFixed(2)}`);
}
footer(lines, total) {
lines.push(`gesamt,${total.toFixed(2)}`);
}
}
class HtmlReport extends Report {
open(lines) {
lines.push("<table>");
}
header(lines) {
lines.push("<tr><th>Bestellung</th><th>Summe</th></tr>");
}
row(lines, order) {
lines.push(`<tr><td>${order.id}</td><td>${order.total.toFixed(2)}</td></tr>`);
}
footer(lines, total) {
lines.push(`<tr><td>Gesamt</td><td>${total.toFixed(2)}</td></tr>`);
}
close(lines) {
lines.push("</table>");
}
}
const orders = [
{ id: 1001, total: 80, cancelled: false },
{ id: 1002, total: 25.5, cancelled: false },
{ id: 1003, total: 40, cancelled: true },
];
console.log(new CsvReport().export(orders));
console.log(new HtmlReport().export(orders));
Ausgabe
Bestellung,Summe
1001,80.00
1002,25.50
gesamt,105.50
<table>
<tr><th>Bestellung</th><th>Summe</th></tr>
<tr><td>1001</td><td>80.00</td></tr>
<tr><td>1002</td><td>25.50</td></tr>
<tr><td>Gesamt</td><td>105.50</td></tr>
</table>

class Report {
export(orders) {
const lines = [];
this.open(lines);
this.header(lines);
let total = 0;
for (const order of orders) {
if (order.cancelled) {
continue;
}
this.row(lines, order);
total += order.total;
}
this.footer(lines, total);
this.close(lines);
return lines.join("\n");
}
open(lines) {}
header(lines) {
throw new Error("header() muss geschrieben werden");
}
row(lines, order) {
throw new Error("row() muss geschrieben werden");
}
footer(lines, total) {
throw new Error("footer() muss geschrieben werden");
}
close(lines) {}
}
Schritt für Schritt, in Worten
  1. new CsvReport().export(orders): Das Gerüst steckt in Report. Es bestimmt die Reihenfolge der Schritte.
  2. open: CsvReport schreibt diesen Schritt nicht, deshalb läuft der leere Rumpf aus Report. Es wird nichts hinzugefügt.
  3. header: Das Gerüst ruft den Schritt auf, und CsvReport schreibt seine Zeile.
  4. row für Bestellung 1001: Das Gerüst ruft den Schritt auf, und CsvReport schreibt seine Zeile.
  5. row für Bestellung 1002: Das Gerüst ruft den Schritt auf, und CsvReport schreibt seine Zeile.
  6. Bestellung 1003 ist storniert: Das Gerüst selbst überspringt sie mit continue. Kein Bericht muss sich diese Regel merken.
  7. footer: Das Gerüst ruft den Schritt auf, und CsvReport schreibt seine Zeile.
  8. close: CsvReport schreibt diesen Schritt nicht, deshalb läuft der leere Rumpf aus Report. Es wird nichts hinzugefügt.
  9. Jetzt HtmlReport: dasselbe Gerüst, andere Schritte.
  10. open: Das Gerüst ruft den Schritt auf, und HtmlReport schreibt seine Zeile.
  11. header: Das Gerüst ruft den Schritt auf, und HtmlReport schreibt seine Zeile.
  12. row für Bestellung 1001: Das Gerüst ruft den Schritt auf, und HtmlReport schreibt seine Zeile.
  13. row für Bestellung 1002: Das Gerüst ruft den Schritt auf, und HtmlReport schreibt seine Zeile.
  14. Bestellung 1003 ist storniert: Das Gerüst selbst überspringt sie mit continue. Kein Bericht muss sich diese Regel merken.
  15. footer: Das Gerüst ruft den Schritt auf, und HtmlReport schreibt seine Zeile.
  16. close: Das Gerüst ruft den Schritt auf, und HtmlReport schreibt seine Zeile.
  17. Zwei Berichte, ein Gerüst. Beide Summen sind 105.50 €, weil die Regel zu stornierten Bestellungen an einer einzigen Stelle steht.

Die Summe ist in beiden Berichten 105.50 €: Die Regel zu stornierten Bestellungen steckt im Gerüst, an einer einzigen Stelle.

Sieh es dir an

Das Gerüst wird nicht angefasst

JavaScript hat kein final. Eine Unterklasse kann ihr eigenes export schreiben, und nichts hält sie auf. Ein fehlender Schritt zeigt sich erst, wenn das Gerüst ihn erreicht:

class TextReport extends Report {
header(lines) {
lines.push("Bestellung Summe");
}
row(lines, order) {
lines.push(`${order.id} ${order.total.toFixed(2)}`);
}
}
console.log(new TextReport().export(orders));
Fehler
Error: footer() muss geschrieben werden

Deshalb läuft jeder neue Bericht mindestens einmal, bevor er bei der Buchhaltung ankommt.

Sieh es dir an

Ohne Vererbung: die Schritte als Funktionen

Die Schritte müssen keine Methoden einer Unterklasse sein. Das Gerüst kann sie als Parameter nehmen: Die Kopfzeile ist Text, und die Zeile und die Summe sind Funktionen.

function exportOrders(orders, header, row, footer) {
const lines = [header];
let total = 0;
for (const order of orders) {
if (order.cancelled) {
continue;
}
lines.push(row(order));
total += order.total;
}
lines.push(footer(total));
return lines.join("\n");
}
console.log(exportOrders(
orders,
"Bestellung,Summe",
(order) => `${order.id},${order.total.toFixed(2)}`,
(total) => `gesamt,${total.toFixed(2)}`,
));
console.log(exportOrders(
orders,
"<table>\n<tr><th>Bestellung</th><th>Summe</th></tr>",
(order) => `<tr><td>${order.id}</td><td>${order.total.toFixed(2)}</td></tr>`,
(total) => `<tr><td>Gesamt</td><td>${total.toFixed(2)}</td></tr>\n</table>`,
));
Ausgabe
Bestellung,Summe
1001,80.00
1002,25.50
gesamt,105.50
<table>
<tr><th>Bestellung</th><th>Summe</th></tr>
<tr><td>1001</td><td>80.00</td></tr>
<tr><td>1002</td><td>25.50</td></tr>
<tr><td>Gesamt</td><td>105.50</td></tr>
</table>

Das Gerüst steckt weiterhin an einer einzigen Stelle, und stornierte Bestellungen zählen weiterhin nicht.

In JavaScript ist das oft der natürlichere Weg: Eine Funktion ist ein Wert, und es braucht keine Vererbung. Eine Unterklasse lohnt sich, wenn es viele Schritte gibt oder sie Daten teilen (zum Beispiel die aktuelle Zeilennummer), die besser in den Feldern eines einzigen Objekts liegen.

Problem

Jeder, der die Bestellungen will, blättert die Seiten um

Die Bestellungen liegen in einem System, das sie seitenweise liefert: zwei pro Anfrage, weil eine Anfrage langsam ist. Hier ist die Quelle eine Liste im Speicher, und jedes Laden gibt eine Zeile aus, damit du siehst, wann es passiert:

class OrderSource {
constructor(orders) {
this.orders = orders;
}
fetchPage(number) {
console.log(`Seite wird geladen ${number}`);
const start = (number - 1) * 2;
return this.orders.slice(start, start + 2);
}
}

Der Bericht, die E-Mail an die Kunden und der Export wollen alle Bestellungen, und jeder blättert die Seiten selbst um:

let number = 1;
let page = source.fetchPage(number);
while (page.length > 0) {
for (const order of page) {
console.log(order.id);
}
number++;
page = source.fetchPage(number);
}
Ausgabe
Seite wird geladen 1
1001
1002
Seite wird geladen 2
1003
1004
Seite wird geladen 3
1005
Seite wird geladen 4

Der Code, der nur „jede Bestellung der Reihe nach“ will, weiß, dass es Seiten gibt, wie sie gezählt werden und dass das Ende eine leere Seite ist. Dieselben Zeilen stehen in drei Dateien. Wenn das System von Seitenzahlen auf „einen Schlüssel für die nächste Seite“ umsteigt, änderst du alle drei.

Die Idee

Iterator: etwas hinter einem Cursor durchlaufen

Der Aufrufer will eines: die nächste Bestellung, solange es eine gibt. Wie man zu ihr kommt (eine Liste, Seiten, eine Datei, das Netzwerk), ist die Sache von jemand anderem.

Dieser jemand ist der Cursor: ein Objekt, das sich merkt, wie weit es gekommen ist, und die Frage „gibt es noch mehr?“ selbst beantwortet, wobei es eine neue Seite erst lädt, wenn die vorige zu Ende ist. Der Aufrufer schreibt ein gewöhnliches for...of und weiß nichts von den Seiten.

Das ist das Muster Iterator. Es hat zwei Rollen:

  • die Collection: das, was durchlaufen wird. Sie liefert einen Cursor;
  • der Cursor: merkt sich die Stelle und liefert das nächste Element.

Dieses Muster ist in jede der vier Sprachen eingebaut: for...of funktioniert mit jedem Objekt, das einen Cursor liefert. In JavaScript ist der Cursor ein Objekt mit next(), und der einfachste Weg, einen zu bauen, ist ein Generator: eine Funktion mit function* und yield.

Sieh es dir an

Der Cursor, der die Seiten lädt

function* macht einen Generator: Ihn aufzurufen tut noch nichts, er gibt einen Cursor zurück. Jedes Mal, wenn for...of nach der nächsten Bestellung fragt, läuft die Funktion bis zum nächsten yield, gibt die Bestellung heraus und hält genau dort an. Deshalb wird die nächste Seite erst geladen, wenn die aktuelle zu Ende ist:
function* allOrders(source) {
for (let number = 1; ; number++) {
const page = source.fetchPage(number);
if (page.length === 0) {
return;
}
for (const order of page) {
yield order;
}
}
}

Der Aufrufer weiß nichts von den Seiten:

for (const order of allOrders(source)) {
console.log(order.id);
}
Ausgabe
Seite wird geladen 1
1001
1002
Seite wird geladen 2
1003
1004
Seite wird geladen 3
1005
Seite wird geladen 4

function* allOrders(source) {
for (let number = 1; ; number++) {
const page = source.fetchPage(number);
if (page.length === 0) {
return;
}
for (const order of page) {
yield order;
}
}
}
for (const order of allOrders(source)) {
console.log(order.id);
}
Schritt für Schritt, in Worten
  1. Die Schleife verlangt die erste Bestellung. Noch ist nichts geladen.
  2. Der Generator hat noch keine Seite, deshalb lädt er Seite 1.
  3. 1001: Die erste Bestellung der Seite geht an die Schleife, und die Schleife gibt sie aus.
  4. 1002: von derselben Seite. Es wird nichts geladen.
  5. Die Seite ist zu Ende. Erst jetzt lädt der Cursor Seite 2.
  6. 1003 und 1004 von Seite 2.
  7. Wieder die Grenze: Seite 3.
  8. 1005: Auf Seite 3 steht nur eine Bestellung.
  9. Seite 4 ist leer: Es gibt keine Bestellungen mehr.
  10. Der Cursor sagt „keine mehr“, und die Schleife endet. Die Schleife hat nie eine Seite gesehen.

Die Ausgabe ist dieselbe, und das Zählen der Seiten steckt an einer einzigen Stelle. Wenn das System die Art ändert, wie es Seiten liefert, änderst du den Generator, und die drei Stellen, die die Bestellungen durchlaufen, bleiben unberührt.

Sieh es dir an

Was for-each innen macht

for...of ist eine Kurzschreibweise für diese Schleife mit dem Cursor:

const it = allOrders(source)[Symbol.iterator]();
for (let step = it.next(); !step.done; step = it.next()) {
const order = step.value;
console.log(order.id);
}
Ausgabe
Seite wird geladen 1
1001
1002
Seite wird geladen 2
1003
1004
Seite wird geladen 3
1005
Seite wird geladen 4
for...of ruft einmal [Symbol.iterator]() auf und dann bei jedem Schritt next(), bis done zu true wird. Ein Generator ist sein eigener Cursor: [Symbol.iterator]() gibt den Generator selbst zurück.

Willst du etwas, das sich jedes Mal wieder durchlaufen lässt wie eine Liste, schreibe eine Klasse, die bei jedem Durchlauf einen neuen Generator liefert:

class AllOrders {
constructor(source) {
this.source = source;
}
[Symbol.iterator]() {
return allOrders(this.source);
}
}

Jetzt beginnt for (const order of new AllOrders(source)) bei jedem Durchlauf von vorn, genau wie ein Iterable in Java.

Probier es aus

Sage die Ausgabe voraus

Die Schleife hört nach der dritten Bestellung auf. Was gibt das Programm aus?

let shown = 0;
for (const order of allOrders(source)) {
console.log(order.id);
shown++;
if (shown === 3) {
break;
}
}
Antwort

Probier es aus

Finde den Fehler

Die E-Mail an die Kunden sagt zuerst, wie viele Bestellungen es sind, und listet sie dann auf:

const orders = allOrders(new OrderSource(all));
let count = 0;
for (const order of orders) {
count++;
}
console.log(`Bestellungen: ${count}`);
for (const order of orders) {
console.log(order.id);
}
Ausgabe
Seite wird geladen 1
Seite wird geladen 2
Seite wird geladen 3
Seite wird geladen 4
Bestellungen: 5
Die Anzahl ist 5, aber die Nummern kommen nicht heraus. Welche Zeile musst du ändern?

Wähle die Zeile mit dem Fehler.

Die Idee

Wann du sie nicht brauchst

Template Method hat einen Preis: eine Basisklasse und Vererbung, und Vererbung ist eine Bindung, die sich schwer lösen lässt. Es lohnt sich nicht, wenn:

  • es ein einziges Format gibt. Eine einzige Funktion ohne Schritte ist klarer;
  • es ein oder zwei Schritte gibt. Reiche sie als Funktionen weiter, wie in der Karte „Ohne Vererbung“;
  • die Unterklassen auch die Reihenfolge der Schritte ändern wollen. Dann ist das Gerüst nicht gemeinsam, und wenn du es erzwingst, bekommst du Schritte mit einem if darin.

Einen eigenen Iterator brauchst du nicht, wenn die Daten schon in einer Array liegen: Sie lässt sich schon durchlaufen. Du schreibst einen eigenen, wenn dahinter etwas steckt, das keine Collection im Speicher ist: Seiten, eine zeilenweise gelesene Datei, ein Baum oder eine endlose Folge (Rechnungsnummern).

Übung

Ein Bericht in Markdown

Löse die Aufgabe in deinem Editor.

Markdown. Die Dokumentationsseite will den Bericht als Markdown-Tabelle. Schreibe MarkdownReport, der nur die Schritte schreibt. Die Kopfzeile besteht aus zwei Zeilen. Report und die anderen Berichte werden nicht angefasst. Mit den Bestellungen aus der Lektion:

Ausgabe
| Bestellung | Summe |
|---|---|
| 1001 | 80.00 |
| 1002 | 25.50 |
| **Gesamt** | 105.50 |

Weitere Aufgaben

  • Zeilennummern. Der HTML-Bericht nummeriert seine Zeilen (<td>1</td>, <td>2</td>), und stornierte Bestellungen zählen nicht. Wo hältst du den Zähler: im Gerüst oder in HtmlReport?
  • Die ersten N. Schreibe einen Generator, der nur die ersten N Bestellungen aus einem anderen Cursor liefert. Wie viele Seiten werden für die ersten drei geladen?
  • Nur die großen. Laufe über die Bestellungen der Quelle und liefere nur die über 30 €, wieder ohne dass der Aufrufer etwas von den Seiten weiß.

Test

Teste dich

1. Der Shop will den Bericht auch als JSON. Was schreibst du mit Template Method?
2. Warum hat der Schritt open in der Basisklasse einen leeren Rumpf, header aber nicht?
3. Eine Schleife läuft über den Generator der Bestellungen und hört bei der zweiten mit break auf. Wie viele Seiten werden geladen?
4. Ein Generator wurde einmal bis zum Ende durchlaufen. Was macht ein zweites for mit demselben Generator?

Erstellt von Ivo Gergov im Rahmen der Kampagne von Evo Tech für zugängliche Programmierausbildung ·