SOLID-Prinzipien entmystifiziert – Einführung

Das Erstellen komplexer Software ist sowohl aufregend als auch herausfordernd, aber es ist noch herausfordernder und deprimierender, wenn schlecht geschriebene Software gewartet und aktualisiert wird.

Die Methode, mit der wir großartigen und gut strukturierten Code schreiben, besteht darin, eine Reihe von Prinzipien zu befolgen und einzuhalten, die als SOLID-Prinzipien bezeichnet werden .

Die SOLID-Prinzipien wurden erstmals von dem Informatiker Robert C. Martin in seinem im Jahr 2000 veröffentlichten Artikel vorgestellt .

Schauen wir uns das Akronym SOLID an:

(S) Grundsatz der Gesamtverantwortung ←

Eine Klasse darf nur für einen einzigen Zweck verantwortlich sein, was bedeutet, dass eine Klasse nur eine Art von Aufgabe zu erfüllen hat, wie z. B. (Datenbanklogik, Protokollierungslogik usw.).

(O)pen/Closed-Prinzip ←

Eine Klasse muss für Erweiterungen offen und für Modifikationen geschlossen sein, was bedeutet, dass eine vorhandene Klasse erweiterbar sein muss, ohne dass sie neu geschrieben werden muss, um neue Funktionalität zu implementieren.

(L) iskov Substitutionsprinzip ←

Übergeordnete Klassen müssen problemlos durch ihre untergeordneten Klassen ersetzbar sein, d. h. wenn die Klasse Rectangle ein Untertyp der Klasse Shape ist, sollten wir in der Lage sein, Shape durch Rectangle zu ersetzen, ohne den funktionalen Fluss zu unterbrechen.

(I) Prinzip der Schnittstellentrennung ←

Schnittstellen dürfen Klassen nicht dazu zwingen, Funktionen zu implementieren, die sie nicht unterstützen, was bedeutet, dass größere Schnittstellen in kleinere aufgeteilt werden sollten, um Unterstützung zu bieten.

(D) Prinzip der Abhängigkeitsinversion ←

Klassen müssen von Abstraktion, aber nicht von Konkretion abhängen, was bedeutet, dass High-Level-Module nicht von Low-Level-Modulen abhängen dürfen. Beide müssen von der Abstraktion abhängen.