Entwurfsmuster (Design Patterns): GoF-Klassiker.

1994, Gamma, Helm, Johnson, Vlissides ("Gang of Four") veröffentlichen 23 Entwurfsmuster für objektorientierte Software. Bis heute Pflicht in jeder SE-Klausur.

Die Idee in einem Satz

Entwurfsmuster: Bewährte Lösung für ein wiederkehrendes Entwurfs-Problem in einem bestimmten Kontext.

Warum Muster?

Stell dir vor, du baust Software ohne sie:

• Singleton → "Wie sorge ich dafür, dass es nur EINE Datenbank-Verbindung gibt?"
• Factory → "Wie erstelle ich Objekte, ohne überall new ConcreteClass() zu schreiben?"
• Observer → "Wie informiere ich 10 Komponenten, wenn ein Wert sich ändert?"

Diese Probleme tauchen IMMER WIEDER auf. Muster sind die kondensierten Lösungen aus 50 Jahren OOP-Erfahrung.

Die 3 Pattern-Kategorien

Die 4 wichtigsten Patterns (Klausur-Klassiker)

1. Singleton (Erzeugung)

Problem: Es soll nur EINE Instanz einer Klasse geben (z.B. Logger, DB-Connection, Config).

public class Logger {
    private static Logger instance;

    private Logger() {} // private! niemand kann new Logger() machen

    public static Logger getInstance() {
        if (instance == null) {
            instance = new Logger();
        }
        return instance;
    }

    public void log(String msg) {
        System.out.println("[LOG] " + msg);
    }
}

// Verwendung:
Logger.getInstance().log("Hallo");
Logger.getInstance().log("Welt");
// Beide Aufrufe nutzen DIESELBE Instanz!

Vorteile: Globaler Zugriff, kontrollierter Lifecycle. Nachteile: "Globale Variable in OOP-Verkleidung", schwer zu testen, oft Anti-Pattern.

2. Factory (Erzeugung)

Problem: Objekt-Erzeugung soll von der KONKRETEN Klasse entkoppelt werden.

// Ohne Factory:
Tier tier = new Hund(); // Code kennt Hund-Klasse
Tier tier2 = new Katze();

// Mit Factory:
interface Tier {
    void laut();
}
class Hund implements Tier { public void laut() { System.out.println("Wuff!"); } }
class Katze implements Tier { public void laut() { System.out.println("Miau!"); } }

class TierFactory {
    public static Tier erzeuge(String typ) {
        return switch (typ) {
            case "hund" -> new Hund();
            case "katze" -> new Katze();
            default -> throw new IllegalArgumentException();
        };
    }
}

// Verwendung:
Tier tier = TierFactory.erzeuge("hund");
tier.laut(); // Wuff!
// Code kennt nur das Interface Tier, nicht die konkrete Klasse!

Vorteil: Lose Kopplung, einfacher zu erweitern.

3. Observer (Verhalten)

Problem: Wenn sich ein Objekt ändert, sollen mehrere andere Objekte benachrichtigt werden.

interface Observer {
    void update(String event);
}

class NewsAgentur {
    private List<Observer> abonnenten = new ArrayList<>();

    public void abonniere(Observer o) {
        abonnenten.add(o);
    }

    public void publish(String news) {
        for (Observer o : abonnenten) {
            o.update(news); // alle benachrichtigen
        }
    }
}

class EmailNotifier implements Observer {
    public void update(String e) { System.out.println("EMAIL: " + e); }
}
class PushNotifier implements Observer {
    public void update(String e) { System.out.println("PUSH: " + e); }
}

// Verwendung:
NewsAgentur agentur = new NewsAgentur();
agentur.abonniere(new EmailNotifier());
agentur.abonniere(new PushNotifier());
agentur.publish("Eilmeldung!");
// Beide Notifier werden informiert!

Vorteil: Lose Kopplung zwischen Subject und Observer. Klassiker: UI-Frameworks (React, Vue), Event-Listeners, Pub-Sub-Systeme.

4. Strategy (Verhalten)

Problem: Verschiedene Algorithmen sollen austauschbar sein.

interface SortStrategy {
    void sort(int[] arr);
}

class BubbleSortStrategy implements SortStrategy {
    public void sort(int[] arr) { /* Bubblesort */ }
}
class QuicksortStrategy implements SortStrategy {
    public void sort(int[] arr) { /* Quicksort */ }
}

class Sortierer {
    private SortStrategy strategy;

    public Sortierer(SortStrategy s) {
        this.strategy = s;
    }

    public void sortiere(int[] arr) {
        strategy.sort(arr);
    }
}

// Verwendung:
Sortierer s1 = new Sortierer(new BubbleSortStrategy());
Sortierer s2 = new Sortierer(new QuicksortStrategy());
// Verhalten ändert sich, nicht die Klasse!

Vorteil: Algorithmus zur Laufzeit austauschbar, Open/Closed-Prinzip.

Weitere häufige Patterns (Übersicht)

SOLID-Prinzipien (oft mit Patterns kombiniert)

Klausur-Faustregeln

1. 3 Kategorien: Creational (Erzeugung), Structural (Struktur), Behavioral (Verhalten).

2. Singleton: EINE Instanz. Private Konstruktor, statische getInstance().

3. Factory: Erzeugt Objekte ohne neue\ KonkreteKlasse() aufzurufen, gibt nur das Interface zurück.

4. Observer: Subject + Observer. Subject ruft observer.update() bei Änderung.

5. Strategy: Algorithmus als Interface, konkrete Implementierungen austauschbar.

6. Pattern ≠ Bibliothek. Pattern ist eine Lösungs-Schablone, kein fertiger Code.

Häufige Stolpersteine

1. Singleton überall nutzen. FALSCH. Singleton ist ein Anti-Pattern, wenn du es als globale Variable missbrauchst. Nur dort, wo wirklich nur EINE Instanz Sinn macht (Logger, Config).

2. Factory mit Builder verwechseln. Factory erzeugt EIN Objekt mit einer Methode. Builder konstruiert ein KOMPLEXES Objekt in mehreren Schritten ("schritt1.schritt2.schritt3.build()").

3. Observer = Pub-Sub. Stimmt zur Hälfte. Beim klassischen Observer kennt das Subject seine Observer (Liste). Bei Pub-Sub gibt es einen Broker dazwischen, Subject und Subscriber kennen sich NICHT direkt.

4. Patterns sind Pflicht. FALSCH. Wenn du keine Wiederverwendbarkeit/Erweiterbarkeit brauchst, ist ein Pattern nur Overhead. "YAGNI" (You Ain't Gonna Need It) gilt auch hier.

5. Strategy mit State verwechseln. Strategy = Algorithmus austauschen (z.B. Sortier-Algo). State = Verhalten basiert auf internem Zustand (z.B. Ampel-Zustand).

Patterns Schritt für Schritt

Wähle ein Pattern und sieh, wie es funktioniert. Pro Pattern: Problem, UML-Skizze, Code-Schritte, Verwendungs-Beispiel.

Klausur-Tipp: In der Klausur wird oft ein Code-Beispiel gezeigt und die Frage gestellt: "Welches Pattern liegt vor?". Indikatoren: privater Konstruktor + getInstance() = Singleton. Methode gibt Interface zurück basierend auf Parameter = Factory. Klasse mit Liste von Listenern + notify() = Observer. Interface + austauschbare Implementierungen = Strategy.

Entwurfsmuster, Praxis-Übung

6 Aufgaben zu Klassifikation, Anwendungsbereichen und Code-Beispielen.

Entwurfsmuster, Klausur-Quiz

6 typische Klausurfragen.