Die 5 SOLID Prinzipien erklärt: Praktische Beispiele für besseren Code

Die SOLID-Prinzipien gehören zu den wichtigsten Konzepten in der Softwareentwicklung - aber hand aufs Herz: Wie oft wendest du sie wirklich bewusst an? In diesem Artikel schauen wir uns gemeinsam an, wie du diese oft zitierten aber selten richtig verstandenen Prinzipien praktisch umsetzen kannst.

Was bedeutet SOLID überhaupt?

Bevor wir in die Details eintauchen, lass uns kurz klären, wofür SOLID eigentlich steht:

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Das Single Responsibility Principle verstehen

Kennst du das? Du öffnest eine Klasse und findest darin gefühlt die halbe Anwendungslogik. Genau das möchte das Single Responsibility Principle verhindern. Es besagt, dass jede Klasse nur eine einzige Aufgabe haben sollte.

Praktisches Beispiel: Der UserService

Ein klassisches Beispiel ist der berüchtigte UserService. Anfangs enthält er vielleicht nur simple CRUD-Operationen. Doch mit der Zeit sammeln sich immer mehr Funktionen an:

• Benutzerauthentifizierung
• E-Mail-Versand
• Profilaktualisierung
• Berechtigungsprüfung

Die Lösung? Teile den Service in spezialisierte Klassen auf:

• UserAuthenticationService
• UserEmailService
• UserProfileService
• UserPermissionService

Das Open/Closed Principle in der Praxis

Das Open/Closed Principle klingt zunächst widersprüchlich: Software soll offen für Erweiterungen, aber geschlossen für Änderungen sein. Wie soll das funktionieren?

Beispiel: Ein Zahlungssystem

Stellen wir uns ein Zahlungssystem vor. Statt einer monolithischen PaymentProcessor-Klasse erstellen wir ein Interface:

interface PaymentMethod {
  processPayment(amount: number): boolean;
}

Neue Zahlungsmethoden können jetzt einfach implementiert werden:

class CreditCardPayment implements PaymentMethod {
  processPayment(amount: number): boolean {
    // Implementierung
  }
}

class PayPalPayment implements PaymentMethod {
  processPayment(amount: number): boolean {
    // Implementierung
  }
}

Das Liskov Substitution Principle richtig anwenden

Das Liskov Substitution Principle ist vielleicht das am häufigsten missverstandene SOLID-Prinzip. Es geht darum, dass Unterklassen ihre Basisklassen vollständig ersetzen können müssen.

Das klassische Vogel-Beispiel

Ein häufig genutztes Beispiel ist die Vogel-Hierarchie:

class Bird {
  fly(): void {
    // Flugverhalten
  }
}

class Penguin extends Bird {
  fly(): void {
    throw new Error("Pinguine können nicht fliegen!"); // Verletzt LSP!
  }
}

Die bessere Lösung wäre eine klare Trennung:

interface Bird {
  move(): void;
}

interface FlyingBird extends Bird {
  fly(): void;
}

Interface Segregation: Weniger ist mehr

Das Interface Segregation Principle verhindert, dass Klassen Methoden implementieren müssen, die sie gar nicht brauchen.

Beispiel: Ein schlankes Logging-System

Statt eines großen Logger-Interfaces:

interface Logger {
  logInfo(message: string): void;
  logWarning(message: string): void;
  logError(message: string): void;
  sendEmail(error: Error): void; // Nicht jeder Logger braucht das!
}

Erstellen wir spezialisierte Interfaces:

interface BasicLogger {
  logInfo(message: string): void;
  logWarning(message: string): void;
  logError(message: string): void;
}

interface EmailNotifier {
  sendEmail(error: Error): void;
}

Dependency Inversion: Der Schlüssel zu testbarem Code

Das Dependency Inversion Principle ist der Grundstein für gut testbaren Code. Es empfiehlt, von Abstraktionen statt von konkreten Implementierungen abhängig zu sein.

Praktische Umsetzung

Statt:

class UserController {
  private database = new MySQLDatabase();
}

Besser:

class UserController {
  constructor(private database: Database) {}
}

Best Practices für die SOLID-Implementierung

• Starte klein und refaktoriere schrittweise
• Nutze Code-Reviews um SOLID-Verletzungen zu erkennen
• Setze Unit Tests ein, um das Verhalten zu validieren
• Dokumentiere deine Designentscheidungen

Häufige Fallstricke vermeiden

• Überengineering durch zu viele Abstraktionen
• Zu frühe Optimierung
• Vernachlässigung der Wartbarkeit
• Ignorieren des Team-Kontexts

Fazit: SOLID in der echten Welt

Die SOLID-Prinzipien sind keine starren Regeln, sondern Leitlinien für besseren Code. Der Schlüssel liegt darin, sie pragmatisch und situationsgerecht einzusetzen. Manchmal ist eine "gute genug"-Lösung besser als perfekter Code, der nie fertig wird.

Häufig gestellte Fragen

1. Muss ich alle SOLID-Prinzipien gleichzeitig anwenden?

Nein, du kannst die Prinzipien schrittweise einführen. Beginne mit dem Single Responsibility Principle und erweitere von dort aus.

2. Wie erkenne ich, ob meine Klasse zu viele Verantwortlichkeiten hat?

Ein guter Indikator ist, wenn du häufig aus verschiedenen Gründen Änderungen an der gleichen Klasse vornehmen musst. Das deutet auf mehrere Verantwortlichkeiten hin.

3. Führen SOLID-Prinzipien nicht zu zu vielen Klassen und Interfaces?

Das ist ein häufiges Missverständnis. SOLID zielt nicht darauf ab, möglichst viele Klassen zu erstellen, sondern die richtigen Abstraktionen zu finden. Die Anzahl der Klassen sollte sich aus den tatsächlichen Anforderungen ergeben.