SOLID-Prinzipien in TypeScript: Theorie und Praxis mit Beispielen

Einleitung: Warum SOLID in TypeScript wichtig ist

Bei der Entwicklung mit TypeScript, insbesondere in großen Projekten, wird die Aufrechterhaltung von sauberem und flexiblem Code entscheidend. SOLID sind fünf fundamentale Prinzipien der objektorientierten Programmierung, die helfen, skalierbare, leicht testbare und wartbare Anwendungen zu erstellen. Diese Prinzipien sind besonders relevant für TypeScript, das JavaScript um statische Typisierung und Interfaces erweitert und damit leistungsstarke Werkzeuge für ihre Umsetzung bietet.

In diesem Artikel werden wir jedes der fünf SOLID-Prinzipien aus der Perspektive von TypeScript analysieren und die Theorie mit praktischen Codebeispielen untermauern. Sie erfahren, wie Sie diese Prinzipien anwenden können, um die Architektur Ihrer Projekte zu verbessern.

1. Single Responsibility Principle (Prinzip der einzigen Verantwortung)

Theorie: Jede Klasse oder jedes Modul sollte nur einen Grund für eine Änderung haben. Mit anderen Worten, eine Klasse sollte nur für einen Teil der Funktionalität des Programms verantwortlich sein.

Verletzung des Prinzips:

// ❌ Schlecht: Die Klasse ist für Daten, Speicherung und Formatierung verantwortlichclass User {  constructor(public name: string, public email: string) {}

  saveToDatabase(): void {    console.log(`Speichere ${this.name} in der DB`);  }

  generateHTML(): string {    return `<div>${this.name} - ${this.email}</div>`;  }}

Korrektur durch Anwendung von SRP:

// ✅ Gut: Aufteilung der Verantwortung auf drei Klassenclass User {  constructor(public name: string, public email: string) {}}

class UserRepository {  save(user: User): void {    console.log(`Speichere ${user.name} in der DB`);  }}

class UserView {  render(user: User): string {    return `<div>${user.name} - ${user.email}</div>`;  }}

Jetzt hat jede Klasse eine klare, einzige Aufgabe, was das Testen und Ändern des Codes vereinfacht.

2. Open-Closed Principle (Prinzip der Offenheit/Geschlossenheit)

Theorie: Softwareentitäten (Klassen, Module, Funktionen) 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.

Verletzung des Prinzips:

// ❌ Schlecht: Beim Hinzufügen eines neuen Formtyps muss die Klasse AreaCalculator geändert werdenclass AreaCalculator {  calculate(shape: any): number {    if (shape.type === 'circle') {      return Math.PI * shape.radius ** 2;    } else if (shape.type === 'rectangle') {      return shape.width * shape.height;    }    return 0;  }}

Korrektur durch Anwendung von OCP:

// ✅ Gut: Verwendung von Interface und Polymorphieinterface Shape {  area(): number;}

class Circle implements Shape {  constructor(public radius: number) {}  area(): number {    return Math.PI * this.radius ** 2;  }}

class Rectangle implements Shape {  constructor(public width: number, public height: number) {}  area(): number {    return this.width * this.height;  }}

class AreaCalculator {  calculate(shape: Shape): number {    return shape.area(); // Geschlossen für Modifikation, offen für Erweiterung  }}

Jetzt reicht es, um eine neue Form (z. B. Triangle) hinzuzufügen, eine neue Klasse zu erstellen, die das Interface Shape implementiert – ohne AreaCalculator zu ändern.

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

Theorie: Objekte in einem Programm sollten durch Instanzen ihrer Subtypen ersetzbar sein, ohne die Korrektheit des Programms zu beeinträchtigen. Wenn Sie eine Basisklasse und einen Erben haben, sollte der Code, der mit der Basisklasse arbeitet, auch korrekt mit dem Erben funktionieren.

Verletzung des Prinzips:

// ❌ Schle