Muster in Prüfungsaufgaben erkennen
In der IHK-Prüfung wirst du selten gefragt: „Wie funktioniert das Singleton-Pattern?". Stattdessen liest du ein Szenario von 5–10 Sätzen – ein Kunde wünscht etwas, ein System soll etwas können – und sollst selbst erkennen, welches Muster passt. Diese Erkennungsarbeit ist die eigentliche Hürde. Der Trick: jedes Pattern hat Signalwörter und typische Szenarien. „Genau eine Instanz" → Singleton. „Beim Klick werden alle Diagramme aktualisiert" → Observer. „Algorithmus soll austauschbar sein" → Strategy. Diese Lektion trainiert dich systematisch: du bekommst eine Tabelle mit Signalwörtern, ein paar Faustregeln zur Abgrenzung – und dann ein interaktives Pattern-Detective-Spiel mit echten IHK-typischen Szenarien.
1) Die Signalwort-Tabelle
Wenn du in einer Aufgabe diese Formulierungen findest, schaltet sich dein „Pattern-Reflex" ein. Sie sind nicht hundertprozentig eindeutig – aber sie sind extrem starke Hinweise, weil Prüfungsaufgaben die Pattern-Beschreibungen aus dem Gang-of-Four-Buch fast wörtlich umformulieren:
| Signalwörter in der Aufgabe | Pattern |
|---|---|
| „genau eine Instanz", „darf nur einmal existieren", „globaler Zugriff" | Singleton |
| „abhängig vom Typ erzeugen", „je nach Konfiguration", „Erzeugung kapseln" | Factory |
| „automatisch benachrichtigen", „alle Anzeigen aktualisieren", „mehrere reagieren auf Änderung" | Observer |
| „Algorithmus austauschbar", „verschiedene Varianten", „der Benutzer wählt" | Strategy |
| „um zusätzliche Funktion erweitern", „beliebig kombinieren", „dynamisch hinzufügen" | Decorator |
| „Datenbankzugriff kapseln", „Datenquelle austauschbar", „Persistenz vor Logik verbergen" | Repository |
| „Trennung Daten/Darstellung/Steuerung", „UI von Logik trennen", „mehrere Sichten" | MVC |
2) Drei Abgrenzungs-Faustregeln
Bevor du ins Üben gehst, drei häufige Verwechslungen, die in der Prüfung gerne Punkte kosten:
- Strategy vs. State: wenn der Anwender zwischen Varianten wählt → Strategy. Wenn das Objekt selbst seinen Zustand wechselt (z. B. Bestellung: Entwurf → Bezahlt → Versandt) → State.
- Decorator vs. Adapter vs. Proxy: alle drei wickeln ein Objekt ein. Decorator erweitert Funktionalität, Adapter übersetzt Schnittstellen, Proxy kontrolliert den Zugriff (z. B. Caching, Rechteprüfung).
- Factory vs. Builder: Factory erzeugt das passende Objekt in einem Schritt. Builder konstruiert ein komplexes Objekt schrittweise mit vielen optionalen Parametern (typisch:
Pizza.builder().mitKaese().mitSalami().backen()).
3) Strukturierte Vorgehensweise
Wenn du eine Aufgabe vor dir hast, geh in dieser Reihenfolge vor – das ist die Methode, mit der erfahrene Entwickler in Sekunden eine Pattern-Entscheidung treffen:
- Welche Kategorie? Geht es um Erzeugung (Creational), Struktur/Komposition (Structural) oder Verhalten/Kommunikation (Behavioral)? Das reduziert die Auswahl bereits auf ein Drittel.
- Wer kennt wen? Beobachtungs-Beziehungen → Observer. Verbergungs-Beziehungen → Repository/Proxy. Ein-Objekt-wickelt-anderes → Decorator/Adapter.
- Statisch oder dynamisch? Steht zur Compile-Zeit fest, was passieren soll, oder muss zur Laufzeit entschieden werden? Strategy und Factory leben von Laufzeit-Entscheidungen.
- Hauptverb prüfen: „erzeuge" → Creational. „erweitere/kapsele/wrappe" → Structural. „benachrichtige/wähle/wechsle" → Behavioral.
Mehr zu den drei Kategorien siehst du in der Einstiegslektion Warum Entwurfsmuster? – dort sind die Kategorien-Karten interaktiv.
4) Pattern-Detective – das Trainingsspiel
Hier kommen sieben Szenarien im IHK-typischen Stil. Lies sorgfältig, identifiziere das Pattern und wähle aus. Du bekommst sofort Feedback, was richtig war und warum:
5) Negative Beispiele – wo es kein Pattern braucht
Ebenso wichtig wie Mustererkennung: erkennen, wenn kein Pattern angebracht ist. In der Prüfung kann eine Aufgabe auch lauten: „Begründen Sie, warum hier kein Singleton verwendet werden sollte." Typische Indizien:
| Situation | Warum kein Pattern? |
|---|---|
| Eine kleine Klasse mit zwei Methoden, klar abgegrenzte Aufgabe | Pattern ist Overkill, „YAGNI – You aren't gonna need it" |
| Skript-artige Datenverarbeitung, einmalig ausgeführt | Direkte Lösung lesbarer, kein OOP-Overhead nötig |
| Klasse hat von Natur aus mehrere Instanzen (Kunde, Bestellung) | Singleton wäre falsch – diese Klassen müssen vielfach existieren |
| Nur eine Implementierung absehbar | Strategy/Repository sind unnötig – Interface ohne Mehrwert |
Pattern verkomplizieren immer – sie zahlen sich nur aus, wenn sich echte Flexibilitätsanforderungen abzeichnen. Anti-Muster: „Pattern-itis", also alles zwanghaft mit Pattern lösen.
6) Argumentation in der Prüfung
Bei Pattern-Aufgaben bekommst du Punkte nicht nur fürs Erkennen, sondern fürs Begründen. Eine gute Antwort hat drei Bausteine:
- Pattern benennen – „Hier passt das Observer-Pattern."
- Aufgabenmerkmal zitieren – „Die Aufgabenstellung sagt: ‚alle Anzeigen sollen sich automatisch aktualisieren, wenn sich der Wert ändert'."
- Pattern-Mechanik nennen – „Subject hält Liste von Observern, ruft
notify()bei Änderung auf, jeder Observer aktualisiert sich selbst."
So strukturiert kannst du auch dann Punkte holen, wenn dein Pattern-Vorschlag nicht der gewünschte ist, aber dennoch sinnvoll – der Prüfer sieht, dass du das Konzept verstanden hast. Mehr zu typischen Prüfungs-Formulierungen siehst du in IHK-Aufgaben Entwurfsmuster.
Zusammenfassung
Pattern-Erkennung in der IHK-Prüfung läuft fast immer über Signalwörter in der Aufgabenstellung: „genau eine Instanz" → Singleton, „automatisch benachrichtigen" → Observer, „austauschbar" → Strategy, „erweitern um" → Decorator, „kapseln/verbergen" → Repository. Vorgehen: erst Kategorie (Creational/Structural/Behavioral) eingrenzen, dann die typischen Verwechslungen auflösen (Strategy vs. State, Decorator vs. Adapter vs. Proxy, Factory vs. Builder). Antwort in drei Schritten: Pattern benennen, Aufgabenmerkmal zitieren, Mechanik nennen. Und nicht vergessen: nicht jede Aufgabe verlangt ein Pattern – manchmal ist die einfachste Lösung die richtige.
Verwandte Lektionen: IHK-Aufgaben Entwurfsmuster · Warum Entwurfsmuster? · Singleton · und mehrWeitere relevante LektionenFactoryObserverStrategyDecoratorMVCRepositorySOLID-Prinzipien