Als ich anfing, in die Welt der Softwareentwicklung einzutauchen, war ich oft von all den Schlagworten und Konzepten überwältigt, die im Umlauf waren. Eines der Konzepte, das besonders entmutigend schien, waren die SOLID-Prinzipien. Es fühlte sich an, als müssten sich nur „ernsthafte“ Entwickler Sorgen machen. Aber je vertrauter ich mit dem Codieren wurde, desto klarer wurde mir, dass es bei diesen Prinzipien weniger darum geht, ausgefallen zu sein, sondern vielmehr darum, Code zu schreiben, der nicht dazu führt, dass man sich nach ein paar Monaten die Haare ausreißen möchte.

Hier ist also meine Meinung zu den SOLID-Prinzipien in JavaScript – ein geradliniger, praktischer Leitfaden, den ich mir zu Beginn gewünscht hätte.

1. Single-Responsibility-Prinzip (SRP): One Job, Done Well

Was ist das?

Das Single-Responsibility-Prinzip besagt, dass eine Klasse nur einen Grund für eine Änderung haben sollte, was bedeutet, dass sie nur eine Aufgabe oder Verantwortung haben sollte.

Analogie aus dem wirklichen Leben

Stellen Sie sich einen Barista in Ihrem Lieblingscafé vor. Ihre Aufgabe ist es, Kaffee zu kochen. Wenn sie plötzlich anfangen müssen, die Espressomaschine zu reparieren, Gebäck zu servieren und den Müll rauszubringen, wird es chaotisch. So wie sich der Barista auf die Kaffeezubereitung konzentrieren sollte, sollte sich Ihre Klasse darauf konzentrieren, eine Sache gut zu machen.

Beispiel in JavaScript:

Stellen Sie sich vor, Sie haben eine Benutzerklasse, die die Benutzerauthentifizierung, Datenvalidierung und Datenbankspeicherung übernimmt. Es macht zu viel! Indem Sie diese Verantwortlichkeiten in separate Klassen aufteilen, vereinfachen Sie die Verwaltung und Wartung Ihres Codes.

class UserAuthenticator {
  login(user) {
    // handle login
  }
}

class UserDataValidator {
  validate(user) {
    // validate user data
  }
}

class UserDatabase {
  save(user) {
    // save user to the database
  }
}

2. Open/Closed-Prinzip (OCP): Erweitern, nicht modifizieren

Was ist das?

Das Open/Closed-Prinzip besagt, dass Softwareeinheiten für Erweiterungen offen, für Änderungen jedoch geschlossen sein sollten. Mit anderen Worten: Sie sollten in der Lage sein, neue Funktionen hinzuzufügen, ohne vorhandenen Code zu ändern.

Analogie zum wirklichen Leben:

Stellen Sie sich Ihre Lieblingsspielkonsole vor. Sie können neue Spiele, Controller und Zubehör hinzufügen, müssen es dafür aber nicht öffnen und neu verkabeln. Ebenso sollten Sie in der Lage sein, Ihrem Code neue Funktionen hinzuzufügen, ohne seine Kernstruktur zu ändern.

Beispiel in JavaScript:

Angenommen, Sie haben eine Shape-Klasse mit einer Methode zur Berechnung der Fläche. Wenn Sie eine neue Form hinzufügen müssen, beispielsweise ein Dreieck, sollten Sie die vorhandene Klasse nicht ändern müssen. Erweitern Sie es stattdessen.

class Shape {
  area() {
    throw "Area method not implemented";
  }
}

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

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

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

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

3. Liskov-Substitutionsprinzip (LSP): Ersetzbar bleiben

Was ist das?

Das Liskov-Substitutionsprinzip besagt, dass Objekte einer Oberklasse durch Objekte einer Unterklasse ersetzbar sein sollten, ohne die Korrektheit des Programms zu beeinträchtigen.

Analogie zum wirklichen Leben:

Stellen Sie sich vor, Sie mieten ein Auto. Egal, ob Sie eine Limousine oder einen SUV kaufen, Sie erwarten von ihm, dass er über die Grundfunktionen eines Autos verfügt: Er soll fahren, lenken und anhalten. Wenn Ihr Mietwagen völlig andere Bedienelemente erfordern würde, wären Sie in Schwierigkeiten! Ebenso sollten sich Unterklassen so verhalten, dass die von ihrer übergeordneten Klasse gesetzten Erwartungen nicht gebrochen werden.

Beispiel in JavaScript:

Wenn Sie eine Bird-Klasse und eine Penguin-Klasse haben, die diese erweitert, sollte sich der Pinguin immer noch wie ein Vogel verhalten, auch wenn er nicht fliegen kann. Es sollte immer noch laufen, essen und vielleicht sogar schwimmen.

class Bird {
  move() {
    console.log("Flies in the sky");
  }
}

class Penguin extends Bird {
  move() {
    console.log("Swims in the water");
  }
}

const myBird = new Bird();
const myPenguin = new Penguin();

myBird.move(); // Flies in the sky
myPenguin.move(); // Swims in the water

4. Interface Segregation Principle (ISP): Maßgeschneiderte Schnittstellen

Was ist das?

Das Prinzip der Schnittstellentrennung legt nahe, dass Clients nicht gezwungen werden sollten, Schnittstellen zu implementieren, die sie nicht verwenden. Anstatt eine große Schnittstelle zu haben, sollten Sie kleinere, spezifischere erstellen.

Analogie zum wirklichen Leben:

Stellen Sie sich ein Restaurant vor, in dem der Koch gleichzeitig Kellner, Barkeeper und Tellerwäscher sein muss. Es ist überwältigend und ineffizient! Stattdessen sollte jede Rolle ihre spezifischen Aufgaben haben. Ebenso sollten Ihre Schnittstellen spezialisiert und fokussiert sein.

Beispiel in JavaScript:

Wenn Sie über eine Worker-Schnittstelle verfügen, die Methoden wie buildHouse, paintHouse und designHouse enthält, sollte ein Worker, der nur Häuser streicht, nicht alle anderen Methoden implementieren müssen. Teilen Sie es in kleinere Schnittstellen auf.

class Builder {
  build() {
    console.log("Building house...");
  }
}

class Painter {
  paint() {
    console.log("Painting house...");
  }
}

class Designer {
  design() {
    console.log("Designing house...");
  }
}

5. Prinzip der Abhängigkeitsinversion (DIP): Verlassen Sie sich auf Abstraktionen

Was ist das?

Das Abhängigkeitsinversionsprinzip besagt, dass High-Level-Module nicht von Low-Level-Modulen abhängen sollten. Beide sollten von Abstraktionen abhängen.

Analogie zum wirklichen Leben:

Überlegen Sie, wie Sie Ihr Telefonladegerät an eine Steckdose anschließen. Sie müssen die Details der elektrischen Verkabelung innerhalb der Wände nicht kennen – alles, was Sie brauchen, ist die Schnittstelle (die Steckdose), um Ihr Gerät mit Strom zu versorgen. Ebenso sollte Ihr Code von Abstraktionen (Schnittstellen) abhängen, nicht von konkreten Implementierungen.

Beispiel in JavaScript:

Wenn Sie eine LightBulb-Klasse haben, die eine Switch-Klasse direkt steuert, erstellen Sie eine enge Kopplung. Stattdessen sollten beide von einer Schnittstelle wie PowerSource abhängen.

class LightBulb {
  turnOn(powerSource) {
    powerSource.provideElectricity();
    console.log("Light is on");
  }
}

class Switch {
  constructor(powerSource) {
    this.powerSource = powerSource;
  }

  operate() {
    this.powerSource.togglePower();
  }
}

class PowerSource {
  provideElectricity() {
    console.log("Providing electricity");
  }

  togglePower() {
    console.log("Toggling power");
  }
}

Abschluss

Die SOLID-Prinzipien zu beherrschen ist, als würde man lernen, mit einer Reihe bewährter Rezepte zu kochen. Sobald Sie sie verstanden haben, können Sie Code erstellen, der nicht nur funktional, sondern auch elegant und leicht zu warten ist. Wenn Sie also das nächste Mal in ein Codierungsrätsel geraten, denken Sie daran: Dafür gibt es ein Prinzip!

Viel Spaß beim Codieren! ?