SOLID-Prinzipien in JavaScript: Von der Theorie zur Praxis mit Codebeispielen

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

SOLID ist ein Akronym für fünf fundamentale Prinzipien der objektorientierten Programmierung, formuliert von Robert C. Martin (Uncle Bob). Obwohl JavaScript keine klassische OOP-Sprache ist (es verwendet prototypische Vererbung), sind diese Prinzipien auch darauf anwendbar, insbesondere im Kontext von Node.js und modernen Frameworks. Die Einhaltung von SOLID macht den Code flexibler, testbarer und wartbarer. In diesem Artikel werden wir jedes Prinzip mit praktischen Beispielen in JavaScript durchgehen.

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

Eine Klasse oder ein Modul sollte nur einen Grund für eine Änderung haben. Mit anderen Worten, jede Entität sollte für eine bestimmte Aufgabe verantwortlich sein.

Schlechtes Beispiel: Die Klasse User verwaltet gleichzeitig Benutzerdaten und sendet E-Mail-Benachrichtigungen.

class User {    constructor(name, email) {        this.name = name;        this.email = email;    }

    saveToDatabase() {        // Logik zum Speichern in der DB        console.log(`Speichern des Benutzers ${this.name} in der DB`);    }

    sendWelcomeEmail() {        // Logik zum Senden der E-Mail        console.log(`Senden einer Begrüßung an ${this.email}`);    }}

Gutes Beispiel: Aufteilung der Verantwortung auf zwei Klassen.

class User {    constructor(name, email) {        this.name = name;        this.email = email;    }}

class UserRepository {    save(user) {        console.log(`Speichern des Benutzers ${user.name} in der DB`);    }}

class EmailService {    sendWelcome(user) {        console.log(`Senden einer Begrüßung an ${user.email}`);    }}

// Verwendungconst user = new User('Ivan', 'ivan@example.com');const repo = new UserRepository();const emailService = new EmailService();

repo.save(user);emailService.sendWelcome(user);

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

Softwareentitäten sollten offen für Erweiterungen, aber geschlossen für Änderungen sein. Das bedeutet, dass neue Funktionalität durch neuen Code hinzugefügt werden sollte, nicht durch Änderung des bestehenden Codes.

Schlechtes Beispiel: Die Klasse AreaCalculator erfordert eine Änderung, wenn eine neue Form hinzugefügt wird.

class AreaCalculator {    calculate(shape) {        if (shape.type === 'circle') {            return Math.PI * shape.radius ** 2;        } else if (shape.type === 'rectangle') {            return shape.width * shape.height;        }        // Beim Hinzufügen einer neuen Form muss diese Methode geändert werden    }}

Gutes Beispiel: Verwendung von Polymorphismus und Vererbung.

class Shape {    area() {        throw new Error('Die Methode area() muss überschrieben werden');    }}

class Circle extends Shape {    constructor(radius) {        super();        this.radius = radius;    }

    area() {        return Math.PI * this.radius ** 2;    }}

class Rectangle extends Shape {    constructor(width, height) {        super();        this.width = width;        this.height = height;    }

    area() {        return this.width * this.height;    }}

class AreaCalculator {    calculate(shape) {        return shape.area();    }}

// Verwendungconst calculator = new AreaCalculator();const circle = new Circle(5);const rectangle = new Rectangle(4, 6);

console.log(calculator.calculate(circle));    // 78.54console.log(calculator.calculate(rectangle)); // 24

3. L — Liskov Substitution Principle (Liskovsches Substitutionsprinzip)

Objekte in einem Programm sollten durch Instanzen ihrer Unterklassen ersetzbar sein, ohne die Korrektheit des Programms zu beeinträchtigen.