Design Patterns Anfänger 20 min

Was sind Design Patterns?

Design Patterns sind bewaehrte Loesungen fuer typische Software-Probleme. Erfahre, warum sie 2026 nicht alt, sondern wertvoller denn je sind.

Aktualisiert:
Inhaltsverzeichnis

Was sind Design Patterns?

Ein Design Pattern ist eine bewaehrte, wiederverwendbare Loesung fuer ein typisches Problem in der Softwareentwicklung. Nicht eine Code-Bibliothek, sondern eine Idee, eine Struktur, die man in verschiedenen Sprachen und Situationen anwenden kann.

Die bekanntesten Patterns stammen aus dem Buch “Design Patterns” (1994) der Gang of Four (GoF) - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Sie haben die Fachsprache gepraegt, die Entwickler bis heute nutzen.

Warum Patterns?

1. Gemeinsames Vokabular

Wenn du zu einem Kollegen sagst:

“Das hier sollten wir als Observer umsetzen.”

…dann weiss er sofort, was du meinst - ein Event-basiertes System, wo Objekte sich fuer Aenderungen registrieren. Das spart stundenlange Erklaerungen.

2. Bewaehrte Loesungen

Die meisten Software-Probleme sind nicht neu. Jemand hat schon 10-mal ueberlegt, wie man X am besten strukturiert - die beste Loesung heisst dann “Pattern Y”. Warum das Rad neu erfinden?

3. Frameworks verstehen

Fast alle grossen Frameworks nutzen Patterns massiv:

  • React: Observer (useState), Composite (Komponenten-Baum), HOC/Render Props (Decorator)
  • Spring (Java): Dependency Injection, Factory, Singleton
  • Express Middleware: Chain of Responsibility
  • Redux: Command, Memento

Wer Patterns kennt, versteht diese Tools tiefer.

4. Wartbarer Code

Code, der einem bekannten Muster folgt, ist leichter zu verstehen - auch wenn du ihn 6 Monate nicht angeschaut hast. Patterns sind Code-Architektur mit Wiedererkennungswert.

Kritik an Patterns

Wie jede Methodik koennen Patterns missbraucht werden:

Overengineering

Nicht jedes Problem braucht ein Pattern. Ein simples if (isAdmin) braucht keine Strategy Pattern-Hierarchie.

Cargo Cult

“Lasst uns ein Pattern einbauen, weil Patterns modern klingen.” - fuehrt zu unnoetiger Komplexitaet.

Sprachliche Umstaendlichkeit

Viele GoF-Patterns entstanden fuer Java/C++ mit strengen Typsystemen. In Python, JavaScript oder Ruby sind sie oft trivial oder ueberfluessig - dort gibt es elegantere native Loesungen.

Faustregel: Nutze ein Pattern, weil es das Problem loest, nicht weil du ein Pattern einbauen willst.

Die drei Kategorien (GoF)

Creational Patterns - Objekt-Erzeugung

Wie werden Objekte erstellt?

  • Singleton: nur eine Instanz
  • Factory: Erstellung ueber eine separate Methode/Klasse
  • Builder: komplexe Objekte schrittweise bauen
  • Prototype: neue Objekte durch Kopie
  • Abstract Factory: Familien von Objekten

Structural Patterns - Strukturen

Wie werden Objekte zusammengesetzt?

  • Adapter: Interface-Anpassung
  • Decorator: Funktionalitaet hinzufuegen ohne zu vererben
  • Facade: simple Schnittstelle zu komplexem System
  • Composite: Baumstrukturen
  • Proxy: Stellvertreter

Behavioral Patterns - Verhalten

Wie kommunizieren Objekte?

  • Observer: Events / Subscriptions
  • Strategy: austauschbare Algorithmen
  • Command: Aktionen als Objekte
  • Iterator: Durchlauf ueber Sammlungen
  • State: verhaltensabhaengig vom Zustand

Wir behandeln die wichtigsten davon in den naechsten Kapiteln.

Beispiel: Wann Pattern, wann nicht?

Stell dir vor, du willst Log-Ausgaben.

Einfach: Direkte Funktion

def log(msg):
    print(f"[LOG] {msg}")

log("App gestartet")

Das ist genug. Kein Pattern noetig.

Mittel: Unterschiedliche Log-Levels

class Logger:
    def debug(self, msg): print(f"[DEBUG] {msg}")
    def info(self, msg): print(f"[INFO] {msg}")
    def warn(self, msg): print(f"[WARN] {msg}")
    def error(self, msg): print(f"[ERROR] {msg}")

logger = Logger()
logger.info("App gestartet")

Noch einfach.

Komplex: Multi-Destination, formatierbar, konfigurierbar

Jetzt wird’s interessant - hier sind Patterns sinnvoll:

  • Observer: mehrere Logger-Destinationen (Console, File, Slack)
  • Strategy: Formatter austauschbar (JSON, Plain Text, Structured)
  • Factory: Logger-Erzeugung konfigurierbar
  • Chain of Responsibility: Log-Level-Filterung

Das ist genau, was log4j (Java) oder winston (Node) machen.

Patterns sind keine Kopie-Vorlagen

Ein haeufiges Missverstaendnis: Man lernt Patterns, um Code 1:1 zu kopieren. Falsch.

Patterns sind Denk-Werkzeuge. Sie sagen:

  • “Ach, das ist im Grunde Observer - ich kann Events nutzen.”
  • “Das ist Struktur-aehnlich zu Decorator - ich kann Verhalten dynamisch erweitern.”

Dann implementierst du passend zu deiner Sprache und Situation - oft in 10 Zeilen, nicht in einer ganzen Klassen-Hierarchie.

Patterns in modernen Sprachen

Python / JavaScript / Ruby

Viele GoF-Patterns sind hier schon Sprach-Features:

  • Singleton → Modul selbst (Module werden einmal geladen)
  • Iterator → __iter__, Generatoren
  • Command → Funktion als Wert (First-Class Functions)
  • Observer → Events, Callbacks, Hooks

In diesen Sprachen brauchst du Patterns seltener explizit - der Sprachkern macht schon vieles.

Java / C# / C++

Hier sind klassische Patterns wichtiger - die strengen Typ-Systeme erfordern oft mehr Struktur.

Spring (Java) und .NET (C#) Framework nutzen Patterns intensiv.

Moderne Patterns (nicht aus GoF)

Viele neue Patterns sind entstanden, seit das Buch 1994 erschien:

MVC / MVP / MVVM

Architektur fuer UI - Model (Daten), View (Anzeige), Controller/Presenter/ViewModel (Glue).

Repository Pattern

Datenzugriff abstrahieren - das Business-Object spricht nicht direkt mit der DB.

Dependency Injection

Abhaengigkeiten werden von aussen reingegeben, nicht intern erstellt.

Event Sourcing

Zustand wird als Abfolge von Events gespeichert, nicht als aktueller Snapshot.

CQRS

Trennung von Lese- und Schreib-Operationen auf Daten.

Hexagonal Architecture (Ports & Adapters)

Business-Logik im Zentrum, Infrastruktur (DB, UI, externe APIs) als austauschbare Adapter.

Anti-Patterns

Ebenso wichtig: Muster, die man vermeiden sollte:

  • God Object: eine Klasse macht alles
  • Spaghetti Code: keine erkennbare Struktur
  • Magic Numbers/Strings: ueberall 42 und "admin" ohne Kontext
  • Shotgun Surgery: eine Aenderung erfordert Anpassungen an 20 Stellen
  • Primitive Obsession: immer int/string, nie eigene Typen
  • Callback Hell: verschachtelte Callbacks (in JS vor async/await)

Die goldene Mitte

Best Practices:

  1. Verstehe das Problem bevor du ein Pattern waehlst
  2. Einfachste Loesung zuerst - Pattern nur wenn noetig
  3. Refactoring zu Pattern, nicht Pattern-first design
  4. Lerne viele - dann erkennst du sie in echtem Code
  5. SOLID-Prinzipien sind oft wichtiger als spezifische Patterns

Lohnt sich Design Patterns 2026?

Ja, mit Einschraenkungen:

  • Fuer Senior-Rollen oft erwartet
  • Fuer Frameworks und Libraries essentiell
  • Fuer kleine Anfaenger-Projekte overkill
  • Nicht jeder Pattern ist ueberall relevant

Die groessten Benefits:

  • Code-Reviews werden schneller (gemeinsames Vokabular)
  • Open-Source-Code wird lesbarer (du siehst die Patterns)
  • Architektur-Diskussionen auf Senior-Level

Als Naechstes: SOLID-Prinzipien - die Grundregeln fuer guten OOP-Code.

Zurück zum Design Patterns Kurs