Einleitung

Vor fast zwei Jahrzehnten wurden die SOLID-Prinzipien als grundlegende Richtlinien für objektorientiertes Design formuliert. Heute, in einer Ära von TypeScript, React und mikroservicebasierten Architekturen, stellt sich die berechtigte Frage: Sind diese Prinzipien noch zeitgemäß? Nach seht vielem Jahren praktischer Erfahrung in der Softwareentwicklung möchte ich diese Design-Patterns aus der Werkstatt-Perspektive betrachten und zeigen, was davon in modernen Web-Projekten wirklich noch Sinn macht.

SOLID wurde ursprünglich für objektorientierte Programmierung entwickelt, hat sich aber zu einem umfassenderen Konzept für Software-Design und Architektur entwickelt. Schauen wir uns an, welche dieser Prinzipien sich bewährt haben und wie sie heute in der Praxis angewendet werden sollten.

Single Responsibility Principle: Ein Modul, eine Aufgabe

Das Single Responsibility Principle besagt, dass eine Klasse nur einen einzigen Grund haben sollte, sich zu ändern. Klingt zunächst abstrakt, ist aber eines der wichtigsten Werkzeuge, um die Komplexität in Projekten zu managen.

Warum SRP noch immer unverzichtbar ist

In der modernen Webentwicklung gilt dieses Prinzip nicht nur für Klassen. Funktionen, Module, Komponenten, Services und sogar ganze Microservices sollten alle mit einer einzigen Verantwortlichkeit im Hinterkopf entworfen werden. Das macht Code wartbar, testbar und verständlich.

Schauen wir uns ein praktisches Beispiel aus dem Web-Development-Alltag an:

// Schlecht: UserService macht zu viel auf einmal
class UserService {
  getUserById(userId: string) {
    // Datenbankzugriff
  }

  sendNotification(userId: string, message: string) {
    // Email versenden
  }

  validateUserData(userData: any) {
    // Validierung
  }
}

// Besser: Aufgabentrennung
class UserRepository {
  getUserById(userId: string) {
    // Nur Datenbankzugriff
  }
}

class NotificationService {
  sendToUser(userId: string, message: string) {
    // Nur Benachrichtigungen
  }
}

class UserValidator {
  validate(userData: any) {
    // Nur Validierung
  }
}

SRP in verschiedenen Architektur-Patterns

Das Prinzip funktioniert auch bei komplexeren Patterns. Nehmen wir ein API Gateway: Obwohl es viele verschiedene APIs aufruft, hat es genau eine Verantwortung - einen einheitlichen Zugangspunkt zu bieten und die Vielfalt der Microservices dahinter zu verstecken.

Oder ein Transaction Script: Auch wenn das Script viele verschiedene Dinge tut, besteht seine einzige Verantwortung darin, die gesamte Business-Logik einer bestimmten Geschäftsoperation zu beinhalten.

Open-Closed Principle: Wann Erweiterbarkeit wirklich wichtig ist

"Software-Einheiten sollten offen für Erweiterungen, aber geschlossen für Modifikationen sein" - das Open-Closed Principle klingt elegant, ist in der Praxis aber das umstrittenste der SOLID-Prinzipien.

Die Wahrheit über OCP

Meine ehrliche Meinung nach vielen Jahren: Dieses Prinzip sollte nur als letzter Ausweg angewendet werden. In den meisten Fällen ist es besser, Code so zu schreiben, dass er leicht modifizierbar ist, anstatt sich auf komplexe Erweiterungsmechanismen zu verlassen.

Wann OCP wirklich Sinn macht

Es gibt jedoch legitime Anwendungsfälle:

Öffentliche Web-APIs

Bei öffentlichen APIs ist OCP Gold wert. Breaking Changes müssen minimiert werden, daher können Verträge nicht frei geändert werden. Alle Änderungen sollten als Erweiterungen zur bestehenden API erfolgen.

// API Version 1
interface UserResponse {
  id: string;
  name: string;
}

// API Version 2 - Erweiterung statt Änderung
interface UserResponseV2 extends UserResponse {
  email?: string; // Optional hinzugefügt
  avatarUrl?: string;
}

Öffentliche Bibliotheken

Ähnlich wie bei APIs: Wenn du eine öffentliche Library entwickelst, darfst du die API nicht ohne Rückwärtskompatibilität ändern. Hier solltest du auch an Erweiterbarkeit denken - Library-Nutzer möchten möglicherweise das Standardverhalten für ihre Bedürfnisse anpassen.

Wann du OCP ignorieren solltest

Bei Klassen und Modulen einer einzelnen Anwendung sieht die Sache völlig anders aus. Hier solltest du Modifikationen nicht vermeiden - im Gegenteil! Dein Code sollte so offen für Änderungen wie möglich sein. Business-Anforderungen ändern sich, Frameworks ändern sich, Libraries werden aktualisiert. Du musst bereit sein, jederzeit alles zu ändern, einschließlich der Anwendungsarchitektur.

Der Schlüssel dazu? Tests schreiben und Sprachen mit starken Typ-Systemen wie TypeScript verwenden.

Liskov Substitution Principle: Von Vererbung zu Komposition

Das Liskov Substitution Principle besagt, dass Objekte einer Superklasse durch Objekte ihrer Subklassen ersetzbar sein sollten, ohne die Korrektheit des Programms zu beeinträchtigen.

Warum LSP heute weniger relevant ist

In seiner ursprünglichen Form ist LSP ziemlich eng gefasst und behandelt ein spezifisches OOP-Problem. Es hat zwar Design-Features einiger Sprachen beeinflusst, hat aber durch ein anderes Prinzip an Bedeutung verloren: Composition over Inheritance.

Der bessere Weg: Daten und Verhalten trennen

Ein praktischerer Ansatz ist es, Daten von Verhalten zu trennen. Das ist eher "funktional" gedacht, aber wenn du Daten unveränderlich und Funktionen rein machst, eliminierst du eine ganze Klasse von Bugs.

// Schlecht: Vererbung mit versteckten Problemen
class User {
  constructor(public id: number) {}

  getHashCode(): number {
    return 0; // Verletzt LSP - verschiedene User sollten verschiedene Hashcodes haben
  }
}

// Besser: Interface-basiert
interface User {
  id: number;
}

function getUserHashCode(user: User): number {
  return user.id;
}

// Oder mit Composition
class HashableUser {
  constructor(private user: User) {}

  getHashCode(): number {
    return this.user.id;
  }
}

In modernen TypeScript-Projekten solltest du Vererbung wenn möglich vermeiden und stattdessen Interfaces und Composition verwenden. Das macht deinen Code flexibler und vermeidet die Fallstricke, die LSP ursprünglich lösen wollte.

Interface Segregation Principle: Kleine Interfaces, große Wirkung

"Clients sollten nicht gezwungen werden, von Interfaces abzuhängen, die sie nicht nutzen" - dieses Prinzip ist absolut korrekt und in der modernen Softwareentwicklung hochrelevant.

ISP im objektorientierten Kontext

Halte deine Interfaces granular. Implementierungen sollten keine Methoden haben, die "not implemented exceptions" werfen müssen. Je größer deine Interfaces sind, desto öfter ändern sie sich, und desto öfter musst du (oder andere Entwickler) Implementierungen anpassen - was wiederum zu mehr Bugs führt.

// Schlecht: Zu großes Interface
interface DataService {
  save(data: any): Promise<void>;
  load(id: string): Promise<any>;
  delete(id: string): Promise<void>;
  export(): Promise<Blob>;
  import(file: File): Promise<void>;
  backup(): Promise<void>;
  restore(): Promise<void>;
}

// Besser: Aufgeteilt in spezifische Interfaces
interface DataReader {
  load(id: string): Promise<any>;
}

interface DataWriter {
  save(data: any): Promise<void>;
  delete(id: string): Promise<void>;
}

interface DataBackup {
  backup(): Promise<void>;
  restore(): Promise<void>;
}

ISP in der Architektur

Im allgemeinen architektonischen Sinne bedeutet ISP, dass du nach den minimal möglichen Abhängigkeiten zwischen Komponenten suchen solltest. Das ist eine weitere Version des Loose-Coupling-Prinzips - Clients sollten von der geringstmöglichen Funktionalität abhängen.

Versteckte Abhängigkeiten vermeiden

Was oft übersehen wird: Auch zufällige oder implizite Abhängigkeiten sollten vermieden werden. Eine vergessene API-Methode, eine globale Variable oder sogar ein ungenutzter Wert im Scope können versteckte Abhängigkeiten schaffen.

// Schlecht: Get() hängt implizit von HttpClient ab
class WeatherService {
  constructor(
    private httpClient: HttpClient,
    private dbClient: DatabaseClient,
  ) {}

  async init(): Promise<void> {
    const data = await this.httpClient.get('http://api.weather.com/data');
    await this.dbClient.saveWeather(data);
  }

  async get(): Promise<Weather> {
    // Verwendet httpClient nicht, hat ihn aber als Abhängigkeit
    return await this.dbClient.getWeather();
  }
}

// Besser: Granulare Abhängigkeiten
interface WeatherReader {
  getWeather(): Promise<Weather>;
}

interface WeatherWriter {
  saveWeather(data: Weather): Promise<void>;
}

async function initWeather(
  reader: { get(url: string): Promise<any> },
  writer: WeatherWriter,
): Promise<void> {
  const data = await reader.get('http://api.weather.com/data');
  await writer.saveWeather(data);
}

async function getWeather(reader: WeatherReader): Promise<Weather> {
  return await reader.getWeather();
}

Dependency Inversion: Die Architektur-Grundlage

"High-Level-Module sollten nicht von Low-Level-Modulen abhängen. Beide sollten von Abstraktionen abhängen. Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen."

Warum DI das wichtigste Prinzip ist

Dependency Inversion war für mich vor vielen Jahren am schwersten zu verstehen, wahrscheinlich wegen seiner abstrakten Definition. Gleichzeitig ist es das nützlichste in der Praxis, da es Struktur in der Software etabliert - genauer gesagt eine strikte Ordnung von Ebenen und deren Beziehungen.

Software ohne Ordnung wird sehr schnell zum Chaos. Die meisten Architekturen basieren auf diesen Schichten: Multi-Tier-Architektur, Onion-Architektur, oder die aktuell gehypte Sliced Architecture.

DI in der Praxis

// Schlecht: Direkte Abhängigkeiten
class WeatherService {
  async init(): Promise<void> {
    const data = await new HttpClient().get('http://api.weather.com/data');
    await new DatabaseService().saveWeather(data);
  }
}

// Besser: Abstraktion durch Dependency Injection
interface WeatherHttpService {
  getWeatherData(url: string): Promise<WeatherData>;
}

interface WeatherDbService {
  saveWeather(data: WeatherData): Promise<void>;
}

class WeatherService {
  constructor(
    private httpService: WeatherHttpService,
    private dbService: WeatherDbService,
  ) {}

  async init(): Promise<void> {
    const data = await this.httpService.getWeatherData(
      'http://api.weather.com/data',
    );
    await this.dbService.saveWeather(data);
  }
}

// Am besten: Funktional mit minimalen Interfaces
interface WeatherProvider {
  getWeather(url: string): Promise<WeatherData>;
}

interface WeatherStorage {
  save(data: WeatherData): Promise<void>;
}

async function initWeather(
  provider: WeatherProvider,
  storage: WeatherStorage,
): Promise<void> {
  const data = await provider.getWeather('http://api.weather.com/data');
  await storage.save(data);
}

DI in der Makro-Architektur

Dependency Inversion hat auch die Makro-Architektur beeinflusst:

• Authentifizierung: Anstatt die Autorisierung selbst zu handhaben, sollten Anwendungen von einem Autorisierungsserver abhängen (durch die Autorisierungsprotokoll-Abstraktion)
• Asynchrone Kommunikation: Services kommunizieren mit Abstraktionen in Form eines Service Bus oder eines Sets von Queues - das wird der synchronen Kommunikation vorgezogen
• Actor-Frameworks: Actors erstellen keine Geschwister - diese Arbeit wird an den Actor Manager delegiert

Testbarkeit und lose Kopplung

DI ermöglicht Komponenten-Testbarkeit und reduziert Kopplung. Das macht es zu einem allgegenwärtigen und hochnützlichen Prinzip in modernen Entwicklungs-Workflows.

// Dank DI leicht zu testen
class WeatherService {
  constructor(
    private provider: WeatherProvider,
    private storage: WeatherStorage,
  ) {}
}

// Test mit Mocks
describe('WeatherService', () => {
  it('should save weather data', async () => {
    const mockProvider: WeatherProvider = {
      getWeather: jest.fn().mockResolvedValue({ temp: 20 }),
    };
    const mockStorage: WeatherStorage = {
      save: jest.fn(),
    };

    const service = new WeatherService(mockProvider, mockStorage);
    await service.init();

    expect(mockStorage.save).toHaveBeenCalledWith({ temp: 20 });
  });
});

SOLID heute: Praktische Relevanz und sinnvoller Einsatz

Nach dieser Werkstatt-Runde durch die SOLID-Prinzipien wird klar: Die meisten dieser Prinzipien sind heute noch anwendbar, sowohl im OOP- als auch im architektonischen Kontext. Einige haben besser gealtert als andere, aber das Verständnis aller hilft dir, eine allgemeine Intuition für das Schreiben hochwertiger Software zu entwickeln.

Was du mitnehmen solltest

Single Responsibility bleibt fundamental - ob in Funktionen, Komponenten oder Services. Interface Segregation und Dependency Inversion sind unverzichtbar für wartbare Architekturen. Open-Closed sollte mit Bedacht eingesetzt werden - nicht als Dogma, sondern nur wo wirklich nötig. Liskov Substitution hat durch moderne Praktiken wie Composition over Inheritance an Bedeutung verloren.

Der pragmatische Ansatz

SOLID bleibt ein wertvolles Toolkit, aber die Anwendung erfordert Urteilsvermögen statt Dogmatismus. In modernen TypeScript-Projekten bedeutet das:

• Schreibe kleine, fokussierte Module und Funktionen
• Nutze Interfaces für Abstraktion, nicht Vererbung
• Halte Abhängigkeiten explizit und minimal
• Schreibe Tests, die deine Architektur-Entscheidungen absichern
• Sei bereit, Code zu ändern wenn Anforderungen sich ändern

Die Prinzipien sind keine starren Regeln, sondern Werkzeuge in deiner Entwickler-Toolbox. Nutze sie dort, wo sie Sinn machen, und ignoriere sie, wenn pragmatischere Lösungen besser passen. Software-Entwicklung ist Handwerk - und gute Handwerker wissen, wann sie welches Werkzeug einsetzen müssen.

FAQs

Sollte ich SOLID in jedem Projekt anwenden?

Nein, nicht dogmatisch. SOLID-Prinzipien sind Werkzeuge, keine Gesetze. In kleinen Projekten oder Prototypen kann es sinnvoller sein, pragmatisch zu bleiben und Code zu schreiben, der funktioniert. Bei wachsenden Projekten mit mehreren Entwicklern werden diese Prinzipien jedoch zunehmend wichtiger für die Wartbarkeit. Fang mit Single Responsibility und Dependency Inversion an - die bringen den größten praktischen Nutzen.

Wie setze ich SOLID in funktionaler Programmierung ein?

SOLID wurde für OOP entwickelt, aber die Kernideen lassen sich übertragen. Statt Klassen denkst du in Funktionen und Modulen: Eine Funktion = eine Aufgabe (SRP), kleine spezialisierte Interfaces (ISP), und Abhängigkeiten über Parameter injizieren statt global zugreifen (DI). TypeScript macht das mit seinen strukturellen Typen besonders elegant. Der funktionale Ansatz vermeidet viele OOP-Probleme wie LSP von Natur aus.

Was ist wichtiger: SOLID oder Clean Code?

Das ist kein Entweder-oder. SOLID ist ein Teil von Clean Code, aber nicht alles. Clean Code umfasst auch Aspekte wie aussagekräftige Namen, kleine Funktionen, gute Kommentare und Lesbarkeit. SOLID fokussiert sich auf die Architektur-Ebene. In der Praxis brauchst du beides: Sauberen, lesbaren Code auf Mikro-Ebene und solide Architektur-Prinzipien auf Makro-Ebene. Starte mit lesbarem Code und füge architektonische Prinzipien hinzu, wenn dein Projekt wächst.