Warum Entwurfsmuster? Kategorien

Warum Entwurfsmuster? Kategorien und Einführung

Wenn du Klassen und Objekte verstanden hast, Vererbung und Polymorphismus beherrschst und die SOLID-Prinzipien kennst, stellst du irgendwann fest: bestimmte Probleme tauchen in jedem Projekt wieder auf. Wie modelliere ich „es darf nur ein einziges Logger-Objekt geben"? Wie reagiere ich, wenn sich ein Wert ändert und 5 andere Stellen davon erfahren müssen? Wie tausche ich einen Algorithmus zur Laufzeit aus? Für genau solche wiederkehrenden Fragen gibt es Entwurfsmuster – erprobte, dokumentierte Lösungsschablonen. Diese Lektion gibt dir den Überblick: woher Patterns kommen, warum sie wichtig sind, in welche drei Kategorien sie zerfallen und wie sie deine Code-Qualität konkret verbessern.

1) Was ist ein Entwurfsmuster eigentlich?

Ein Entwurfsmuster (Design Pattern) ist eine wiederverwendbare Lösungsschablone für ein häufig auftretendes Entwurfsproblem in der objektorientierten Softwareentwicklung. Wichtig: ein Pattern ist kein Stück Code, das du kopierst – es ist eine Beschreibung, wie Klassen und Objekte zusammenarbeiten sollen, um ein konkretes Problem zu lösen. Du musst es selbst in deine Sprache übersetzen (Java, Python, C#).

Eine schöne Analogie: Entwurfsmuster sind wie Kochrezepte. Das Rezept für Lasagne sagt dir nicht, ob du Knoblauch dazugibst oder italienische Kräuter – aber es sagt dir die Schichten-Struktur: Boden, Sauce, Nudeln, Käse, wiederholen. Genauso sagt das Observer-Pattern nicht, was genau gesendet wird – aber es sagt: „Es gibt ein Subject und Beobachter, die sich registrieren und benachrichtigt werden."

Die berühmtesten Patterns stammen aus dem Buch „Design Patterns" (1994) von Gamma, Helm, Johnson und Vlissides – den Gang of Four (GoF). Sie haben 23 Muster katalogisiert, die bis heute Standard sind. Spätere Bücher haben weitere Patterns hinzugefügt (Enterprise Patterns von Martin Fowler, Cloud Design Patterns), aber die GoF-Muster sind das Fundament. Mehr zur Theorie in Anforderungen und Architektur.

2) Warum überhaupt Patterns? Code-Vergleich

Der direkteste Weg, den Nutzen zu verstehen: Code ohne Pattern neben Code mit Pattern legen. Hier ein typisches Beispiel – Bezahlung in einem Online-Shop mit verschiedenen Zahlungsarten. Klick zwischen den Tabs:

Code-Vergleich – ohne vs. mit Pattern

Der Code „ohne Pattern" funktioniert – aber für jede neue Zahlungsart musst du die Methode bezahle() aufmachen, ein neues else if einbauen und alles erneut testen. Das verletzt das Open-Closed-Principle (offen für Erweiterung, geschlossen für Änderung). Mit dem Strategy-Pattern ist eine neue Zahlungsart einfach eine neue Klasse, die bestehenden bleiben unangetastet.

3) Die drei Kategorien der GoF-Patterns

Die 23 GoF-Muster sind in drei Kategorien eingeteilt, je nach ihrer Aufgabe: Erzeugungsmuster (wie werden Objekte erzeugt?), Strukturmuster (wie werden Objekte zusammengesetzt?) und Verhaltensmuster (wie kommunizieren Objekte?). Klick eine Kategorie für Details:

Die drei Pattern-Kategorien

Erzeugung (Creational)

Wie wird ein Objekt erzeugt? Wer kennt die Klasse? Wie viele Instanzen?

• Singleton
• Factory Method
• Abstract Factory
• Builder
• Prototype

Struktur (Structural)

Wie werden Klassen / Objekte zu größeren Strukturen zusammengesetzt?

• Adapter
• Decorator
• Facade
• Composite
• Proxy

Verhalten (Behavioral)

Wie kommunizieren Objekte? Wer ruft was wann wie auf?

• Observer
• Strategy
• Command
• Iterator
• State

In der IHK-Prüfung musst du nicht alle 23 Muster auswendig kennen. Wichtig sind die 6-8 Klassiker, die in dieser Lektion 2-8 behandelt werden. Aber die Kategorie-Einteilung ist Prüfungswissen – sie hilft, ein Muster aus der Aufgabenstellung herauszulesen: „Wie wird Objekt erzeugt?" → Creational, „Wie hängen Klassen zusammen?" → Structural, „Wie reagiert das System?" → Behavioral.

4) Was Patterns dir bringen – und was nicht

Patterns sind ein Werkzeug, kein Ziel. Sie haben klare Vorteile, aber auch Grenzen. Wer alles zwanghaft als Pattern modelliert, baut „Pattern-Spaghetti" – dann ist der einfache Code besser. Konkret:

Was Patterns bringen	Was Patterns NICHT lösen
Gemeinsames Vokabular – „Mach das mit Observer" ist klarer als 5 Sätze Erklärung	Schlechte Anforderungen – kein Pattern rettet ein unklares Lastenheft
Erprobte Lösungen – jemand hat den Schmerz schon durchlebt	Performance-Probleme – Patterns lösen Struktur, nicht Effizienz
Erweiterbarkeit – neuer Code statt Änderung am alten (OCP)	Bugs – Patterns sind nur die Struktur, die Logik kann immer fehlerhaft sein
Testbarkeit – kleine, fokussierte Klassen sind einfacher zu testen	Über-Engineering vermeiden – Patterns dürfen das nicht selbst werden
Code-Reviews beschleunigen – „warum hast du das so gemacht?" → „Observer"	Schlechtes Datenmodell – ein ER-Modell-Fehler bleibt

Faustregel: Erst Code schreiben, dann nachdenken, ob ein Pattern hilft. Wenn du den Schmerz selbst gespürt hast (etwa zum dritten Mal denselben if-Block aufgemacht), dann ist das Pattern nicht akademisch, sondern befreiend. Wer Patterns zu früh einsetzt, bekommt zu viele Abstraktionen und der Code wird schwerer zu lesen, nicht einfacher.

5) Wie Patterns dokumentiert werden – Pattern-Schablone

Damit jeder weltweit dasselbe Verständnis von einem Pattern hat, gibt es eine standardisierte Dokumentations-Schablone. Jedes Pattern wird so beschrieben:

Name – damit man im Team über das Pattern reden kann („nehmen wir Strategy")
Problem / Motivation – welche typische Situation löst das Pattern?
Lösung – wie wird die Struktur aufgebaut?
Struktur (UML-Diagramm) – welche Klassen / Schnittstellen sind beteiligt? Mehr in UML-Klassendiagramm
Beteiligte (Participants) – welche Rollen gibt es (Subject, Observer, Strategy, Context, …)?
Konsequenzen – Vor- und Nachteile bei Einsatz
Bekannte Verwendungen – wo wird das Pattern in der Praxis genutzt (Java-Standardbibliothek, Spring, ...)?
Verwandte Muster – welche Patterns sind ähnlich / lösen ähnliche Probleme?

In den folgenden Lektionen wirst du diese Struktur in den einzelnen Pattern-Lektionen wiederfinden – das macht das Lernen systematisch. Mehr Dokumentations-Standards in Welche Doku für welchen Zweck?.

6) Anti-Patterns – das Gegenteil

Genauso wichtig wie Patterns ist die Kenntnis von Anti-Patterns: bekannten schlechten Lösungen für häufige Probleme. Sie sehen oft naheliegend aus, führen aber langfristig in Sackgassen:

God Object: eine Klasse, die alles macht – tausende Zeilen, hunderte Methoden. Verstößt fundamental gegen Single-Responsibility.
Spaghetti-Code: kein erkennbarer Aufbau, alle Klassen voneinander abhängig. Schon nach kurzer Zeit unwartbar. Hilft: Strukturmuster.
Copy-Paste-Programmierung: derselbe Code an 12 Stellen. Bei einer Änderung müsstest du an allen Stellen ändern – tust du aber nicht. Hilft: gemeinsame Klasse / Methode (DRY = Don't Repeat Yourself).
Magic Numbers: Zahlen-Konstanten ohne Namen im Code (if (status == 7)). Niemand weiß, was 7 bedeutet. Hilft: Konstanten oder Enums.
Premature Optimization: Code wird kompliziert „für die Performance", obwohl es nie ein Performance-Problem gab. Hilft: erst messen, dann optimieren. Mehr in Debugging.
Cargo Cult Programming: Code aus Stack Overflow kopieren, ohne zu verstehen, warum er funktioniert. Klassischer Junior-Fehler.

7) Patterns vs. Frameworks vs. Bibliotheken

Ein häufiges Missverständnis: Pattern ≠ Framework ≠ Bibliothek. Die Abgrenzung in einem Satz:

Pattern: Idee / Schablone. Du schreibst den Code selbst. „Wie wird gebaut."
Bibliothek (Library): fertige Funktionen / Klassen, die du aufrufst. Du steuerst, sie hilft. Beispiel: jQuery, Lodash.
Framework: ein Gerüst, in das du deinen Code einhängst. Es ruft dich auf, nicht umgekehrt (Inversion of Control). Beispiel: Spring, React, Angular. Frameworks setzen oft Patterns ein – z. B. MVC.

Bei der Make-or-Buy-Entscheidung ist diese Unterscheidung relevant. Mehr zur Toolchain in Build-Tools.

Zusammenfassung

Entwurfsmuster sind erprobte Lösungsschablonen für wiederkehrende Probleme der OOP – wie Kochrezepte, nicht wie fertiger Code. Die 23 GoF-Muster gliedern sich in drei Kategorien: Erzeugung (Objekte erzeugen – Singleton, Factory), Struktur (Klassen zusammensetzen – Decorator, Adapter) und Verhalten (Objekte kommunizieren – Observer, Strategy). Patterns bringen gemeinsames Vokabular, Erweiterbarkeit und Testbarkeit – lösen aber keine schlechten Anforderungen oder Performance-Probleme. Wichtig ist die Kenntnis von Anti-Patterns (God Object, Spaghetti, Copy-Paste, Magic Numbers). Pattern, Bibliothek und Framework sind drei verschiedene Dinge.

Verwandte Lektionen: Singleton · Factory · Observer · und mehrWeitere relevante LektionenSOLID-Prinzipien Abstrakte Klassen & Interfaces Polymorphismus UML-Klassendiagramm Anforderungen erheben Strategy Decorator MVC