SOLID-Prinzipien in JavaScript: Theorie und Praxis

Einführung in die SOLID-Prinzipien in JavaScript

SOLID ist ein Akronym für fünf grundlegende Prinzipien der objektorientierten Programmierung, formuliert von Robert Martin (Uncle Bob). Obwohl JavaScript ursprünglich keine streng typisierte OOP-Sprache war, nutzt modernes JavaScript (ES6+) mit Klassen, Modulen und TypeScript diese Prinzipien aktiv, um skalierbare und wartbare Anwendungen zu erstellen, insbesondere in der Node.js-Umgebung.

In diesem Artikel werden wir jedes der fünf SOLID-Prinzipien anhand praktischer JavaScript-Codebeispiele analysieren. Das Verständnis dieser Prinzipien wird Ihnen helfen, sauberen, flexiblen und änderungsresistenten Code zu schreiben.

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

Das Prinzip besagt: Eine Klasse oder ein Modul sollte nur einen einzigen Grund für Änderungen haben. Mit anderen Worten, jedes Modul ist für eine bestimmte Funktionalität verantwortlich.

Verletzung des SRP

Betrachten wir die Klasse UserService, die gleichzeitig Benutzer verwaltet, E-Mails sendet und Aktionen protokolliert:

class UserService {  constructor() {    this.users = [];  }

  addUser(name) {    this.users.push({ name });    console.log('User added'); // Protokollierung    this.sendEmail(name); // E-Mail senden  }

  sendEmail(name) {    console.log(`Email sent to ${name}`);  }

  getUsers() {    return this.users;  }}

Hier hat die Klasse drei Verantwortlichkeiten: Datenverwaltung, Protokollierung und Versand von Benachrichtigungen. Eine Änderung der Protokollierungslogik oder des E-Mail-Versands würde eine Änderung der Klasse UserService erfordern.

Einhaltung des SRP

Teilen wir die Verantwortlichkeiten in separate Klassen auf:

class Logger {  log(message) {    console.log(`[LOG]: ${message}`);  }}

class EmailService {  send(name) {    console.log(`Email sent to ${name}`);  }}

class UserService {  constructor(logger, emailService) {    this.users = [];    this.logger = logger;    this.emailService = emailService;  }

  addUser(name) {    this.users.push({ name });    this.logger.log(`User ${name} added`);    this.emailService.send(name);  }

  getUsers() {    return this.users;  }}

Jetzt ist jede Klasse für ihre eigene Aufgabe verantwortlich, und Änderungen in einem Dienst wirken sich nicht auf die anderen aus.

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

Das Prinzip besagt: Softwareentitäten sollten für Erweiterungen offen, aber für Modifikationen geschlossen sein. Das bedeutet, wir sollten in der Lage sein, neue Funktionalität hinzuzufügen, ohne vorhandenen Code zu ändern.

Verletzung des OCP

Angenommen, wir haben eine Funktion zur Berechnung der Fläche von Formen:

function calculateArea(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 müsste diese Funktion modifiziert werden}

Einhaltung des OCP

Wir nutzen Polymorphismus durch Klassen:

class Shape {  area() {    throw new Error('Method "area()" must be implemented');  }}

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;  }}

// Neue Form hinzufügen, ohne vorhandenen Code zu ändernclass Triangle extends Shape {  constructor(base, height) {    super();    this.base = base;    this.height = height;  }  area() {    return (this.base * this.height) / 2;  }}

function calculateArea