Design Patterns in der Softwareentwicklung: Die wichtigsten Muster erklärt

Design Patterns sind bewährte Lösungsschablonen für wiederkehrende Probleme in der Softwareentwicklung. Sie helfen Ihnen, flexiblen, wartbaren und erweiterbaren Code zu schreiben. In diesem Artikel stelle ich Ihnen die wichtigsten Entwurfsmuster vor und zeige, wann und wie Sie diese einsetzen sollten.

Was sind Design Patterns?

Design Patterns wurden erstmals 1994 durch das Buch „Design Patterns: Elements of Reusable Object-Oriented Software“ der sogenannten „Gang of Four“ (Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides) systematisch dokumentiert. Diese 23 klassischen Muster bilden bis heute die Grundlage für objektorientierte Softwarearchitektur.

Ein Design Pattern ist keine fertige Lösung, die Sie direkt kopieren können. Es ist vielmehr eine Beschreibung oder Vorlage für die Lösung eines Problems, die Sie an Ihre spezifische Situation anpassen müssen. Patterns helfen Entwicklern, eine gemeinsame Sprache zu sprechen und etablierte Best Practices zu nutzen.

Die drei Kategorien von Design Patterns

Design Patterns werden in drei Hauptkategorien eingeteilt, je nachdem welches Problem sie lösen:

Creational Patterns (Erzeugungsmuster)

Diese Muster beschäftigen sich mit der Objekterzeugung. Sie abstrahieren den Instanziierungsprozess und machen ein System unabhängig davon, wie seine Objekte erzeugt, zusammengesetzt und repräsentiert werden. Zu den Erzeugungsmustern gehören Singleton, Factory Method, Abstract Factory, Builder und Prototype.

Structural Patterns (Strukturmuster)

Strukturmuster befassen sich damit, wie Klassen und Objekte zu größeren Strukturen zusammengesetzt werden können. Sie nutzen Vererbung zur Komposition von Interfaces oder Implementierungen. Bekannte Vertreter sind Adapter, Bridge, Composite, Decorator, Facade, Flyweight und Proxy.

Behavioral Patterns (Verhaltensmuster)

Verhaltensmuster charakterisieren die Art und Weise, wie Klassen oder Objekte miteinander interagieren und Verantwortlichkeiten verteilen. Sie erleichtern die Kommunikation zwischen Objekten. Dazu gehören Observer, Strategy, Command, State, Template Method, Iterator, Mediator, Memento, Visitor und Chain of Responsibility.

Die wichtigsten Design Patterns im Detail

Singleton Pattern

Das Singleton Pattern stellt sicher, dass von einer Klasse nur eine einzige Instanz existiert und bietet einen globalen Zugriffspunkt auf diese Instanz. Dies ist nützlich für Ressourcen, die systemweit nur einmal existieren sollten, etwa Datenbankverbindungen, Logger oder Konfigurationsmanager.

// TypeScript Singleton
class DatabaseConnection {
  private static instance: DatabaseConnection;
  private connection: any;

  private constructor() {
    // Private Konstruktor verhindert direkte Instanziierung
    this.connection = this.createConnection();
  }

  public static getInstance(): DatabaseConnection {
    if (!DatabaseConnection.instance) {
      DatabaseConnection.instance = new DatabaseConnection();
    }
    return DatabaseConnection.instance;
  }

  private createConnection(): any {
    console.log('Datenbankverbindung wird hergestellt...');
    return { connected: true };
  }

  public query(sql: string): void {
    console.log(`Führe Query aus: ${sql}`);
  }
}

// Verwendung
const db1 = DatabaseConnection.getInstance();
const db2 = DatabaseConnection.getInstance();
console.log(db1 === db2); // true - gleiche Instanz

Factory Method Pattern

Das Factory Method Pattern definiert eine Schnittstelle zur Objekterzeugung, überlässt aber den Unterklassen die Entscheidung, welche Klasse instanziiert werden soll. Dieses Muster ist besonders nützlich, wenn der genaue Typ des zu erstellenden Objekts erst zur Laufzeit bekannt ist oder wenn Sie die Objekterzeugung von der Verwendung entkoppeln möchten.

// TypeScript Factory Method
interface Notification {
  send(message: string): void;
}

class EmailNotification implements Notification {
  send(message: string): void {
    console.log(`E-Mail gesendet: ${message}`);
  }
}

class SMSNotification implements Notification {
  send(message: string): void {
    console.log(`SMS gesendet: ${message}`);
  }
}

class PushNotification implements Notification {
  send(message: string): void {
    console.log(`Push-Nachricht gesendet: ${message}`);
  }
}

// Factory
class NotificationFactory {
  static createNotification(type: 'email' | 'sms' | 'push'): Notification {
    switch (type) {
      case 'email':
        return new EmailNotification();
      case 'sms':
        return new SMSNotification();
      case 'push':
        return new PushNotification();
      default:
        throw new Error(`Unbekannter Notification-Typ: ${type}`);
    }
  }
}

// Verwendung
const notification = NotificationFactory.createNotification('email');
notification.send('Willkommen!');

Observer Pattern

Das Observer Pattern definiert eine Eins-zu-Viele-Abhängigkeit zwischen Objekten, sodass bei Zustandsänderungen eines Objekts alle abhängigen Objekte automatisch benachrichtigt und aktualisiert werden. Dieses Muster ist die Grundlage für reaktive Programmierung und Event-Systeme.

// TypeScript Observer
interface Observer {
  update(data: any): void;
}

interface Subject {
  attach(observer: Observer): void;
  detach(observer: Observer): void;
  notify(): void;
}

class NewsPublisher implements Subject {
  private observers: Observer[] = [];
  private latestNews: string = '';

  attach(observer: Observer): void {
    this.observers.push(observer);
  }

  detach(observer: Observer): void {
    const index = this.observers.indexOf(observer);
    if (index > -1) {
      this.observers.splice(index, 1);
    }
  }

  notify(): void {
    for (const observer of this.observers) {
      observer.update(this.latestNews);
    }
  }

  publishNews(news: string): void {
    this.latestNews = news;
    console.log(`Neue Nachricht: ${news}`);
    this.notify();
  }
}

class NewsSubscriber implements Observer {
  constructor(private name: string) {}

  update(news: string): void {
    console.log(`${this.name} hat Nachricht erhalten: ${news}`);
  }
}

// Verwendung
const publisher = new NewsPublisher();
const subscriber1 = new NewsSubscriber('Abonnent A');
const subscriber2 = new NewsSubscriber('Abonnent B');

publisher.attach(subscriber1);
publisher.attach(subscriber2);
publisher.publishNews('Neue Produktversion verfügbar!');

Strategy Pattern

Das Strategy Pattern definiert eine Familie von Algorithmen, kapselt jeden einzelnen und macht sie austauschbar. Dieses Muster ermöglicht es, den Algorithmus unabhängig von den Clients, die ihn verwenden, zu variieren. Es ist ideal, wenn Sie verschiedene Varianten eines Algorithmus haben und zur Laufzeit zwischen ihnen wechseln möchten.

// TypeScript Strategy
interface PaymentStrategy {
  pay(amount: number): void;
}

class CreditCardPayment implements PaymentStrategy {
  constructor(private cardNumber: string) {}

  pay(amount: number): void {
    console.log(`${amount}€ mit Kreditkarte ${this.cardNumber} bezahlt`);
  }
}

class PayPalPayment implements PaymentStrategy {
  constructor(private email: string) {}

  pay(amount: number): void {
    console.log(`${amount}€ mit PayPal (${this.email}) bezahlt`);
  }
}

class BankTransferPayment implements PaymentStrategy {
  constructor(private iban: string) {}

  pay(amount: number): void {
    console.log(`${amount}€ per Überweisung an ${this.iban}`);
  }
}

// Context
class ShoppingCart {
  private items: { name: string; price: number }[] = [];
  private paymentStrategy: PaymentStrategy;

  setPaymentStrategy(strategy: PaymentStrategy): void {
    this.paymentStrategy = strategy;
  }

  addItem(name: string, price: number): void {
    this.items.push({ name, price });
  }

  checkout(): void {
    const total = this.items.reduce((sum, item) => sum + item.price, 0);
    this.paymentStrategy.pay(total);
  }
}

// Verwendung
const cart = new ShoppingCart();
cart.addItem('Laptop', 999);
cart.addItem('Maus', 29);

cart.setPaymentStrategy(new CreditCardPayment('1234-5678-9012-3456'));
cart.checkout();

cart.setPaymentStrategy(new PayPalPayment('kunde@example.com'));
cart.checkout();

Decorator Pattern

Das Decorator Pattern fügt einem Objekt dynamisch zusätzliche Verantwortlichkeiten hinzu. Decorators bieten eine flexible Alternative zur Unterklassenbildung, um Funktionalität zu erweitern. Sie können mehrere Decorators verschachteln, um komplexe Kombinationen von Verhalten zu erstellen.

// TypeScript Decorator
interface Coffee {
  getCost(): number;
  getDescription(): string;
}

class SimpleCoffee implements Coffee {
  getCost(): number {
    return 2.50;
  }

  getDescription(): string {
    return 'Kaffee';
  }
}

// Basis-Decorator
abstract class CoffeeDecorator implements Coffee {
  constructor(protected coffee: Coffee) {}

  getCost(): number {
    return this.coffee.getCost();
  }

  getDescription(): string {
    return this.coffee.getDescription();
  }
}

class MilkDecorator extends CoffeeDecorator {
  getCost(): number {
    return this.coffee.getCost() + 0.50;
  }

  getDescription(): string {
    return `${this.coffee.getDescription()} + Milch`;
  }
}

class SugarDecorator extends CoffeeDecorator {
  getCost(): number {
    return this.coffee.getCost() + 0.20;
  }

  getDescription(): string {
    return `${this.coffee.getDescription()} + Zucker`;
  }
}

class WhippedCreamDecorator extends CoffeeDecorator {
  getCost(): number {
    return this.coffee.getCost() + 0.70;
  }

  getDescription(): string {
    return `${this.coffee.getDescription()} + Sahne`;
  }
}

// Verwendung
let myCoffee: Coffee = new SimpleCoffee();
console.log(`${myCoffee.getDescription()}: ${myCoffee.getCost()}€`);

myCoffee = new MilkDecorator(myCoffee);
myCoffee = new SugarDecorator(myCoffee);
myCoffee = new WhippedCreamDecorator(myCoffee);
console.log(`${myCoffee.getDescription()}: ${myCoffee.getCost()}€`);

Adapter Pattern

Das Adapter Pattern konvertiert die Schnittstelle einer Klasse in eine andere Schnittstelle, die Clients erwarten. Adapter ermöglichen die Zusammenarbeit von Klassen, die sonst aufgrund inkompatibler Schnittstellen nicht zusammenarbeiten könnten. Dieses Muster ist besonders nützlich bei der Integration von Drittanbieter-Bibliotheken oder Legacy-Code.

// TypeScript Adapter
// Legacy-System mit alter Schnittstelle
class OldPaymentSystem {
  processOldPayment(
    accountNumber: string,
    amount: number,
    currency: string
  ): boolean {
    console.log(`Legacy-Zahlung: ${amount} ${currency} von Konto ${accountNumber}`);
    return true;
  }
}

// Neue, erwartete Schnittstelle
interface ModernPaymentProcessor {
  pay(payment: {
    userId: string;
    amount: number;
    currency: string;
  }): Promise<{ success: boolean; transactionId: string }>;
}

// Adapter
class PaymentAdapter implements ModernPaymentProcessor {
  constructor(private legacySystem: OldPaymentSystem) {}

  async pay(payment: {
    userId: string;
    amount: number;
    currency: string;
  }): Promise<{ success: boolean; transactionId: string }> {
    // Adaptiert die neue Schnittstelle auf das Legacy-System
    const accountNumber = this.getUserAccount(payment.userId);
    const success = this.legacySystem.processOldPayment(
      accountNumber,
      payment.amount,
      payment.currency
    );

    return {
      success,
      transactionId: `TXN-${Date.now()}`
    };
  }

  private getUserAccount(userId: string): string {
    // Mapping von userId zu accountNumber
    return `ACC-${userId}`;
  }
}

// Verwendung
const legacySystem = new OldPaymentSystem();
const modernPayment: ModernPaymentProcessor = new PaymentAdapter(legacySystem);

modernPayment.pay({
  userId: '12345',
  amount: 99.99,
  currency: 'EUR'
});

Builder Pattern

Das Builder Pattern trennt die Konstruktion eines komplexen Objekts von seiner Repräsentation, sodass derselbe Konstruktionsprozess verschiedene Repräsentationen erzeugen kann. Es ist besonders nützlich, wenn ein Objekt viele optionale Parameter hat oder wenn die Konstruktion mehrere Schritte erfordert.

// TypeScript Builder
class Computer {
  constructor(
    public cpu: string,
    public ram: number,
    public storage: number,
    public gpu?: string,
    public hasWifi?: boolean,
    public hasBluetooth?: boolean
  ) {}

  toString(): string {
    return `Computer: CPU=${this.cpu}, RAM=${this.ram}GB, Storage=${this.storage}GB, GPU=${this.gpu || 'integriert'}, WiFi=${this.hasWifi}, Bluetooth=${this.hasBluetooth}`;
  }
}

class ComputerBuilder {
  private cpu: string = '';
  private ram: number = 8;
  private storage: number = 256;
  private gpu?: string;
  private hasWifi: boolean = true;
  private hasBluetooth: boolean = true;

  setCpu(cpu: string): ComputerBuilder {
    this.cpu = cpu;
    return this;
  }

  setRam(ram: number): ComputerBuilder {
    this.ram = ram;
    return this;
  }

  setStorage(storage: number): ComputerBuilder {
    this.storage = storage;
    return this;
  }

  setGpu(gpu: string): ComputerBuilder {
    this.gpu = gpu;
    return this;
  }

  setWifi(hasWifi: boolean): ComputerBuilder {
    this.hasWifi = hasWifi;
    return this;
  }

  setBluetooth(hasBluetooth: boolean): ComputerBuilder {
    this.hasBluetooth = hasBluetooth;
    return this;
  }

  build(): Computer {
    return new Computer(
      this.cpu,
      this.ram,
      this.storage,
      this.gpu,
      this.hasWifi,
      this.hasBluetooth
    );
  }
}

// Verwendung mit Fluent Interface
const gamingPC = new ComputerBuilder()
  .setCpu('Intel i9-13900K')
  .setRam(64)
  .setStorage(2000)
  .setGpu('NVIDIA RTX 4090')
  .setWifi(true)
  .setBluetooth(true)
  .build();

const officePC = new ComputerBuilder()
  .setCpu('Intel i5-13400')
  .setRam(16)
  .setStorage(512)
  .build();

console.log(gamingPC.toString());
console.log(officePC.toString());

Übersicht: Wann welches Pattern einsetzen?

Pattern	Kategorie	Anwendungsfall
Singleton	Creational	Genau eine Instanz benötigt (Logger, Config)
Factory Method	Creational	Objekttyp zur Laufzeit bestimmen
Builder	Creational	Komplexe Objekte schrittweise aufbauen
Observer	Behavioral	Reaktion auf Zustandsänderungen
Strategy	Behavioral	Algorithmen austauschbar machen
Decorator	Structural	Funktionalität dynamisch erweitern
Adapter	Structural	Inkompatible Schnittstellen verbinden

Design Patterns in der Praxis: Best Practices

Häufige Fehler beim Einsatz von Design Patterns

Obwohl Design Patterns wertvolle Werkzeuge sind, können sie bei falscher Anwendung mehr schaden als nutzen. Hier sind typische Fallstricke, die Sie vermeiden sollten: