Aufgabe 12 - Jahresprojekt Sprint 3 - Review, Schichten und Adapter

Lernziele

Du erkennst übertriebenen Mustereinsatz (Patternitis) und setzt eine angemessene, einfachere Lösung dagegen.
Du schließt Sprint 3 mit Review, Retrospektive und Release ab.
Du prüfst die Schichten deines Projekts auf die Abhängigkeitsrichtung Darstellung → Fachlogik → Datenzugriff und behebst einen Verstoß.
Du kapselst eine fremde Bibliothek oder Schnittstelle hinter einem Adapter und ergänzt Verhalten mit Decorator-Schichten.
Du ordnest die Muster deines Projekts in einer Muster-Landkarte vom Problem aus.

Ausgangslage

Dritte und letzte Woche von Sprint 3. Kapitel 18 schließt den Musterblock ab: Adapter (eine fremde Schnittstelle in die eigene übersetzen), Decorator (Verhalten in Schichten ergänzen), MVC und Schichten (Darstellung, Fachlogik und Datenzugriff trennen, Abhängigkeiten nur nach unten) und die wichtigste Fähigkeit von allen: sich begründet gegen ein Muster zu entscheiden. Euer Projekt ist inzwischen groß genug, dass sich falsche Abhängigkeiten eingeschlichen haben können. Heute schaut ihr nach.

Die Kata: Dateigrößen formatieren. Ein Teammitglied hat diesen Code für die Anzeige von Dateigrößen eingereicht. Er funktioniert:

interface SizeFormattingStrategy {
  format(bytes: number): string;
}

class MegabyteFormattingStrategy implements SizeFormattingStrategy {
  format(bytes: number): string {
    return `${(bytes / 1_000_000).toFixed(1)} MB`;
  }
}

class SizeFormatterFactory {
  private static instance: SizeFormatterFactory | null = null;

  private constructor() {}

  static getInstance(): SizeFormatterFactory {
    if (SizeFormatterFactory.instance === null) SizeFormatterFactory.instance = new SizeFormatterFactory();
    return SizeFormatterFactory.instance;
  }

  createStrategy(): SizeFormattingStrategy {
    return new MegabyteFormattingStrategy();
  }
}

class FileSizeLabel {
  constructor(
    private readonly strategy: SizeFormattingStrategy = SizeFormatterFactory.getInstance().createStrategy(),
  ) {}

  render(bytes: number): string {
    return this.strategy.format(bytes);
  }
}

console.log(new FileSizeLabel().render(2_450_000));

Dafür brauchst du:

Kapitel 18 Entwurfsmuster III – Struktur und Architektur (Adapter, Decorator, MVC und Schichten, Muster-Landkarte, Patternitis).
Kapitel 05 bis 07 für Review, Retrospektive und Release.
Euer Design-Review mit den Steckbriefen aus Aufgabe 10 und 11.

Allgemein

Projektordner anlegen siehe https://qiz.at/projektordner

Lies vorher kurz https://qiz.at/assignmentsabgabe durch.
Nur vollständige Abgaben (siehe https://qiz.at/rules) können positiv bewertet werden.
Abgabe- und Testdetails siehe https://qiz.at/assignmentsabgabe
Abgegeben wird dein Projektordner mit der Kata (Code und README.md) und den Links auf Sprint-Protokoll, Release, Issues, Merge Requests und Abschnitte im docs/design-review.md des Jahresprojekts. Bezeichner und Kommentare im Code sind Englisch.
Wer was beigetragen hat, zeigen Board, Merge Requests und /spend-Einträge (Kapitel 07).

Wesentlich_überwiegend

Aufgabe

Kata: Schreibe ein kurzes Patternitis-Review: Welche Muster sind hier im Einsatz, welches Problem soll jedes lösen, und warum gibt es dieses Problem im Code nicht? Schreibe die angemessene Lösung (vermutlich unter fünf Zeilen) und belege mit einem Vergleich, dass sie dasselbe Ergebnis liefert.
Review von Sprint 3: Vorführung Story für Story gegen die Akzeptanzkriterien, Sprint-Protokoll mit abgenommenen und zurückgelegten Stories, Sprint-Ziel erreicht oder nicht (mit Ursache) und Velocity. Die Lehrkraft geht während der Praxiszeit von Team zu Team (etwa zehn Minuten je Team); bis sie bei euch ist, arbeitet ihr an der Kata und am Projektteil weiter.
Retrospektive: Maßnahme aus Sprint 2 überprüfen, eine neue überprüfbare Maßnahme mit verantwortlicher Person festhalten.

Tipp: Stell für jede Fundstelle der Kata die Frage aus Kapitel 18: Löst ein Muster genau dieses Problem, und verdient es seinen Aufwand? Dein Gegenentwurf muss gleich viel können wie die Vorlage.

Bewertungskriterien

Vollständig, wenn:

das Review Singleton, Factory und Strategy je mit behauptetem Problem nennt und begründet, warum es fehlt,
der Gegenentwurf kürzer ist und für mindestens zwei Eingaben dasselbe Ergebnis wie die Vorlage liefert,
das Sprint-Protokoll und die Retrospektive vollständig sind (wie in Sprint 2).

Abgabe

Wie unter Allgemein.

Wesentlich_vollständig

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

Release von Sprint 3 nach Kapitel 07.
Schichtenprüfung: Ordnet die Ordner und wichtigsten Dateien eures Projekts den drei Schichten Darstellung, Fachlogik und Datenzugriff zu (Tabelle im Design-Review). Prüft die Importe: Zeigt jede Abhängigkeit nur nach unten? Notiert jeden Verstoß mit Datei und Zeile, zum Beispiel eine Komponente, die direkt die Datenbank anspricht, oder Fachlogik, die etwas aus der Oberfläche importiert.
Behebt den schwersten Verstoß in einem Merge Request und haltet fest, was danach ohne Oberfläche testbar ist.

Tipp: Beim Prüfen hilft die Frage aus Kapitel 18: Wer darf wen kennen? Die Fachlogik weiß nichts von der Darstellung. Eine Suche nach import in den Dateien der Fachlogik zeigt schnell, was sie kennt.

Bewertungskriterien

Vollständig, wenn:

Release-Merge-Request, Tag, Release und geschlossener Milestone Sprint 3 existieren,
die Schichtentabelle alle Ordner zuordnet und jeder gefundene Verstoß mit Datei und Zeile belegt ist (oder die Prüfung ohne Befund nachvollziehbar dokumentiert ist),
der schwerste Verstoß im Merge Request behoben ist und der Gewinn für die Testbarkeit benannt ist.

Abgabe

Wie unter Allgemein.

PlusPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

Adapter im Projekt: Wählt eine fremde Bibliothek oder Schnittstelle, die euer Projekt verwendet (Speicher, Medienverarbeitung, externe API). Kapselt sie hinter einem eigenen Interface: ein Adapter übersetzt zwischen eurem Interface und der fremden Schnittstelle, und nur die Datei des Adapters kennt die Bibliothek.
Prüft den Adapter isoliert mit einem Test (ohne die echte fremde Schnittstelle, mit einer simulierten).
Schreibt den Steckbrief und haltet fest, wie viele Dateien ein Wechsel der Bibliothek jetzt berühren würde.

Tipp: Einen Adapter erkennt man am Übersetzen: andere Namen, andere Einheiten, andere Struktur. Hat euer Projekt keine fremde Schnittstelle, nehmt die Datenzugriffs-Implementierung aus Aufgabe 09 und prüft, ob sie schon ein Adapter ist.

Bewertungskriterien

Vollständig, wenn:

nur der Adapter die fremde Bibliothek importiert und der übrige Code das eigene Interface verwendet,
der Adapter isoliert getestet ist und der Test grün ist,
der Steckbrief vorliegt und die Zahl der bei einem Wechsel berührten Dateien belegt ist.

Abgabe

Wie unter Allgemein.

MandalorianPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

Decorator: Baue einen Decorator um euren Adapter oder euer Repository, der Verhalten ergänzt, ohne den Kern zu ändern (zum Beispiel Protokollieren jedes Aufrufs oder eine Wiederholung bei einem Fehler). Ein Test zeigt, dass der Decorator dasselbe Interface erfüllt, den Kern aufruft und keinen Fehler verschluckt.
Muster-Landkarte des Projekts: Lege im Design-Review eine Tabelle mit den acht Mustern des Jahres (Singleton, Factory, Observer, Strategy, Command, Adapter, Decorator, MVC/Schichten) an, gruppiert in Erzeugung, Verhalten, Struktur und Architektur. Je Muster: eine Leitfrage, die das Problem beschreibt und sich mit Ja oder Nein beantworten lässt, und die Antwort für euer Projekt (eingesetzt mit Verweis auf den Steckbrief oder bewusst verzichtet mit Grund).

Tipp: Eine Leitfrage, die schon den Musternamen enthält, hilft bei der Entscheidung nicht. Probiere beim Decorator beide Reihenfolgen der Schichten aus.

Bewertungskriterien

Vollständig, wenn:

der Decorator dasselbe Interface erfüllt, den Kern unverändert lässt und der Test grün ist,
die Landkarte alle acht Muster in vier Kategorien mit je einer problembezogenen Ja-Nein-Leitfrage und einer begründeten Antwort fürs eigene Projekt enthält.

Abgabe

Wie unter Allgemein.

Zeit dafür

Durchschnittlich bis Wesentlich_vollständig: ca. 70 min (5 min Board-Check, 10 min Kata, 25 min Review und Retrospektive, 30 min Release und Schichtenprüfung)

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules