Aufgabe 04 - Mustererkennung

Aufgabe 04 - Mustererkennung

Worum geht es?

Muster erkennt man erst, wenn man sie einmal gesehen hat. Sie durchsuchen bekannten Code - auch Ihren eigenen - nach Entwurfsmustern, die dort längst leben, benennen die Beteiligten und ihre Rollen und begründen den Nutzen am Fundort. Nebenbei legen Sie die erste Karte Ihrer Muster-Sammlung an, die über die nächsten Wochen wächst (siehe Kapitel Entwurfsmuster I).

Was Sie dafür brauchen

• Kapitel Entwurfsmuster I (Muster-Idee, Singleton, Factory, SOLID).
• Ihre Projekte aus der 3. und 4. Klasse; die Dokumentation einer Bibliothek Ihrer Wahl.
• Das gemeinsam definierte Steckbrief-Format der Klasse.

Welche Kompetenzen Sie erwerben und zeigen

• Sie erkennen Entwurfsmuster in bestehendem Code und ordnen den Beteiligten ihre Rolle im Muster zu.
• Sie begründen den Nutzen eines Musters am konkreten Fundort.
• Sie verbinden ein gefundenes Muster mit dem SOLID-Prinzip, das es stützt.

Pädagogische Einordnung

• Reproduktion: Muster im eigenen Code wiedererkennen und benennen (Teil A).
• Reorganisation und Transfer: Muster in Frameworks aufspüren und als Steckbrief festhalten (Teile B und C).
• Reflexion, Problemlösung und Urteilsbildung: Muster mit SOLID-Prinzipien verknüpfen und übertriebenen Einsatz erkennen (Teil D).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt. Teil D ist der Expertenteil.

Teil A - Archäologie im eigenen Code

Suchen Sie in Ihren eigenen Projekten mindestens vier Muster-Vorkommen (Kandidaten: die Repository-Factory aus SEW-4-Aufgabe 18 → Factory; addEventListener/Event-Emitter → Observer; die Sensor-Schnittstelle aus SEW-3-Aufgabe 13 → Strategy-Verwandtschaft; Ihre Middleware → Decorator-Idee). Für jedes Vorkommen: Codestelle (Auszug), Mustername, wer spielt welche Rolle, und was ohne das Muster schlechter wäre.

Teil B - Frameworks lesen

1. Singleton: Wo sorgt Ihr Buffet-Projekt (oder Next.js selbst) dafür, dass es genau eine Datenbankverbindung gibt? Falls nirgends: Bauen Sie es als Modul-Singleton ein und erklären Sie, warum das in Node/TypeScript besonders einfach ist.
2. Finden Sie in der Dokumentation einer Bibliothek Ihrer Wahl ein explizit benanntes Muster (Frameworks reden offen darüber) und fassen Sie den Abschnitt in drei Sätzen zusammen.

Teil C - Steckbriefe

Erstellen Sie für Singleton und Factory je einen Muster-Steckbrief im Klassenformat (Minimum: Problem, Lösung als UML, Mini-Implementierung in TypeScript mit maximal 20 Zeilen, ein Trade-off, eine Fundstelle). Diese Steckbriefe wachsen über die nächsten Wochen zur Muster-Sammlung der Klasse - Ihrem Matura-Nachschlagewerk.

Teil D - Expertenteil: Muster und SOLID

1. Ordnen Sie jedem der vier Fundstücke aus Teil A das SOLID-Prinzip zu, das es umsetzt (etwa Factory → Open-Closed, Dependency Injection → Dependency Inversion), und begründen Sie die Zuordnung in einem Satz.
2. Suchen Sie eine Stelle in Ihrem Code, an der ein Muster fehlt und deshalb ein SOLID-Prinzip verletzt wird (etwa ein switch, der bei jedem neuen Fall geändert werden muss → Open-Closed). Beschreiben Sie, welches Muster das beheben würde und was der Umbau kosten würde.
3. Gegenprobe gegen Patternitis: Nennen Sie eine Stelle in Ihrem Code, an der ein Muster nicht gerechtfertigt wäre, obwohl es passen könnte, und begründen Sie in zwei Sätzen, warum die einfache Lösung hier die bessere ist.

Wissenscheck

1. Was ist ein Entwurfsmuster - und warum ist sein Name ein Teil des Nutzens?
2. Nennen Sie die drei Musterkategorien und je ein Beispiel.
3. Welche zwei Bausteine tragen das Singleton, und was ist die berechtigte Kritik daran?
4. Wofür stehen die fünf Buchstaben von SOLID?
5. Warum gilt “erst das Problem, dann das Muster” und nicht umgekehrt?

Abgabe

Die Fundstellen-Dokumentation (Teile A und B), die zwei Steckbriefe und die SOLID-Zuordnung samt der beiden Urteile aus Teil D.