SOLID-Prinzipien in TypeScript: Theorie und Praxis von A bis Z

SOLID-Prinzipien in TypeScript: Theorie und Praxis von A bis Z

SOLID ist ein Akronym für fünf grundlegende Prinzipien der objektorientierten Programmierung, formuliert von Robert C. Martin (Uncle Bob). Diese Prinzipien helfen dabei, flexiblen, wartbaren und skalierbaren Code zu erstellen. In diesem Artikel werden wir jedes SOLID-Prinzip mit Beispielen in TypeScript detailliert analysieren, von einfachen Definitionen bis hin zu realen Anwendungsszenarien.

1. Single Responsibility Principle (SRP) — Prinzip der einzigen Verantwortung

Definition: Jede Klasse sollte nur einen einzigen Grund für eine Änderung haben. Mit anderen Worten: Eine Klasse sollte für eine klar definierte Aufgabe verantwortlich sein.

Problem: Wenn eine Klasse mehrere Verantwortlichkeiten übernimmt, wird sie schwer zu testen, zu erweitern und zu warten. Eine Änderung einer Funktion kann eine andere beschädigen.

Beispiel für eine SRP-Verletzung:

// ❌ SRP-Verletzung: Die Klasse kümmert sich um Speicherung, Formatierung und Versand\nclass UserService {\n    saveUser(user: User): void {\n        // Speicherung in der DB\n        console.log('User saved');\n    }\n\n    formatUserData(user: User): string {\n        return `Name: ${user.name}, Email: ${user.email}`;\n    }\n\n    sendWelcomeEmail(user: User): void {\n        // E-Mail-Versand\n        console.log('Email sent');\n    }\n}

Lösung mit SRP:

// ✅ Jede Klasse ist für ihre eigene Aufgabe verantwortlich\nclass UserRepository {\n    save(user: User): void {\n        console.log('User saved');\n    }\n}\n\nclass UserFormatter {\n    format(user: User): string {\n        return `Name: ${user.name}, Email: ${user.email}`;\n    }\n}\n\nclass EmailService {\n    sendWelcome(user: User): void {\n        console.log('Email sent');\n    }\n}

2. Open-Closed Principle (OCP) — Prinzip der Offenheit für Erweiterungen, Geschlossenheit für Änderungen

Definition: Klassen sollten für Erweiterungen offen, aber für Modifikationen geschlossen sein. Das bedeutet, dass Sie neue Funktionalität hinzufügen können sollten, ohne vorhandenen Code zu ändern.

Beispiel für eine OCP-Verletzung:

// ❌ Beim Hinzufügen eines neuen Formtyps muss die Methode calculateArea geändert werden\nclass AreaCalculator {\n    calculateArea(shape: any): number {\n        if (shape.type === 'circle') {\n            return Math.PI * shape.radius ** 2;\n        } else if (shape.type === 'rectangle') {\n            return shape.width * shape.height;\n        }\n        throw new Error('Unknown shape');\n    }\n}

Lösung mit OCP (Verwendung von Polymorphismus):

// ✅ Verwendung von Interface und Vererbung\ninterface Shape {\n    area(): number;\n}\n\nclass Circle implements Shape {\n    constructor(private radius: number) {}\n    area(): number {\n        return Math.PI * this.radius ** 2;\n    }\n}\n\nclass Rectangle implements Shape {\n    constructor(private width: number, private height: number) {}\n    area(): number {\n        return this.width * this.height;\n    }\n}\n\nclass AreaCalculator {\n    calculateArea(shape: Shape): number {\n        return shape.area(); // Erfordert keine Änderungen beim Hinzufügen neuer Formen\n    }\n}

3. Liskov Substitution Principle (LSP) — Prinzip der Substitution von Barbara Liskov

Definition: Objekte in einem Programm sollten durch Instanzen ihrer Untertypen ersetzt werden können, ohne die Korrektheit des Programms zu beeinträchtigen. Eine abgeleitete Klasse darf den Vertrag der Basisklasse nicht verletzen.

Beispiel für eine LSP-Verletzung:

// ❌ Verletzung: Die Unterklasse ändert das Verhalten der Oberklasse\nclass Bird {\n    fly(): void {\n        console.log('Flying');\n    }\n}\n\nclass Penguin extends Bird {\n    fly(): void {\n        throw new Error('Penguins cannot fly!'); // Vertragsverletzung\n    }\n}

Lösung mit LSP:

// ✅ Trennung