10 Prinzipien der objektorientierten Programmierung, die jeder Entwickler kennen sollte

Ich treffe ziemlich oft auf Entwickler, die noch nie von den SOLID-Prinzipien gehört haben (wir haben ausführlich darüber hier berichtet. — Anm. d. Red.) oder von objektorientierter Programmierung (OOP), oder sie haben davon gehört, verwenden sie aber nicht in der Praxis. In diesem Artikel werden die Vorteile der OOP-Prinzipien beschrieben, die Entwicklern in ihrer täglichen Arbeit helfen. Einige davon sind gut bekannt, andere weniger, sodass der Artikel sowohl für Neulinge als auch für erfahrene Programmierer nützlich sein wird.

Wir erinnern daran: für alle Leser von „Habr“ — 10.000 Rubel Rabatt bei der Buchung eines beliebigen Skillbox-Kurses mit dem Promo-Code „Habr“.

Skillbox empfiehlt: Online-Kurs „Java-Entwickler“.

DRY (Don’t Repeat Yourself)

Ein ziemlich einfaches Prinzip, dessen Wesensart aus dem Namen klar ist: „Wiederhole dich nicht“. Für Programmierer bedeutet dies, dass dualer Code vermieden werden sollte, und auch die Möglichkeit gegeben sein muss, Abstraktionen im Arbeitsprozess zu nutzen.

Wenn im Code zwei sich wiederholende Abschnitte vorhanden sind, sollten diese in einer Methode zusammengefasst werden. Wenn ein festgelegter Wert mehr als einmal verwendet wird, sollte er in eine öffentliche Konstante umgewandelt werden.

Das ist notwendig, um den Code zu vereinfachen und seine Wartung zu erleichtern, was das Hauptziel der OOP ist. Man sollte jedoch nicht übertreiben, da derselbe Code nicht sowohl mit OrderId als auch mit SSN bestehen kann.

Kapselung von Änderungen

Softwareprodukte der meisten Unternehmen entwickeln sich ständig weiter. Das bedeutet, dass Änderungen am Code vorgenommen werden müssen und er gewartet werden muss. Man kann sich das Leben durch Kapselung erleichtern. Dies ermöglicht eine effizientere Testung und Wartung des bestehenden Codes. Hier ist eines der Beispiele.

Wenn Sie in Java programmieren, dann weiser Methoden und Variablen standardmäßig private zu.

Prinzip der Offenheit/Abgeschlossenheit

Dieses Prinzip lässt sich leicht merken, wenn man die folgende Aussage liest: „Softwareeinheiten (Klassen, Module, Funktionen usw.) sollten für Erweiterungen offen, aber für Änderungen geschlossen sein.“ Praktisch bedeutet dies, dass sie es ermöglichen sollten, ihr Verhalten zu ändern, ohne den Quellcode zu verändern.

Das Prinzip ist wichtig, wenn Änderungen im Quellcode eine Überprüfung, modulare Tests und andere Verfahren erfordern. Code, der dem Open/Closed-Prinzip entspricht, wird beim Erweitern nicht verändert, weshalb es mit ihm viel weniger Probleme gibt.

Hier ist ein Beispiel für Code, der dieses Prinzip verletzt.

Wenn etwas daran geändert werden muss, wird dies viel Zeit in Anspruch nehmen, da alle Codeabschnitte, die mit dem relevanten Fragment verbunden sind, geändert werden müssen.

Übrigens ist das Open/Closed-Prinzip eines der SOLID-Prinzipien.

Prinzip der einzelnen Verantwortung (SRP)

Ein weiteres Prinzip aus dem SOLID-Set. Es besagt, dass „es nur einen Grund gibt, der zu einer Änderung der Klasse führt“. Eine Klasse erfüllt nur eine Aufgabe. Sie kann mehrere Methoden haben, die jedoch alle nur zur Lösung einer allgemeinen Aufgabe dienen. Alle Methoden und Eigenschaften sollten nur diesem Zweck dienen.

Der Wert dieses Prinzips liegt darin, dass es die Verbindung zwischen einer einzelnen Softwarekomponente und dem Code schwächt. Wenn mehr als eine Funktionalität in eine Klasse eingeführt wird, wird eine Verbindung zwischen zwei Funktionen hergestellt. Wenn man also eine von ihnen ändert, besteht eine hohe Wahrscheinlichkeit, dass man die zweite, die mit der ersten verbunden ist, beschädigt. Das bedeutet, dass die Testzyklen erhöht werden müssen, um alle Probleme im Voraus zu erkennen.

Prinzip der Abhängigkeitsinversion (DIP)

Das oben gezeigte Codebeispiel zeigt, dass der AppManager von EventLogWriter abhängt, der wiederum eng mit dem AppManager verbunden ist. Wenn ein anderer Weg benötigt wird, um Benachrichtigungen anzuzeigen, sei es Push, SMS oder E-Mail, muss die Klasse AppManager geändert werden.

Das Problem kann mit Hilfe des DIP gelöst werden. Statt den AppManager zu verwenden, fordern wir den EventLogWriter an, der über ein Framework eingeführt wird.

DIP ermöglicht es, einzelne Module problemlos durch andere zu ersetzen, indem das Abhängigkeitsmodul geändert wird. Dies ermöglicht es, ein Modul zu ändern, ohne die anderen zu beeinflussen.

Komposition statt Vererbung

Es gibt zwei Hauptwege, um Code wiederzuverwenden: Vererbung und Komposition, wobei jede ihre eigenen Vor- und Nachteile hat. In der Regel wird der zweiten der Vorzug gegeben, da er flexibler ist.

Die Komposition ermöglicht es, das Verhalten einer Klasse zur Laufzeit durch das Setzen ihrer Eigenschaften zu ändern. Bei der Implementierung von Schnittstellen wird Polymorphismus verwendet, der eine flexiblere Implementierung bietet.

Selbst in „Effective Java“ von Joshua Bloch wird empfohlen, die Komposition dem Vererben vorzuziehen.

Das Liskov-Substitutionsprinzip (LSP)

Ein weiteres Prinzip aus dem SOLID-Werkzeugkasten. Es besagt, dass Subtypen durch ihren Supertyp ersetzt werden können. Das heißt, Methoden und Funktionen, die mit der Superklasse arbeiten, sollten auch problemlos mit ihren Unterklassen funktionieren.

Das LSP hängt sowohl mit dem Prinzip der individuellen Verantwortung als auch mit dem Prinzip der Trennung der Verantwortlichkeiten zusammen. Wenn eine Klasse mehr Funktionalität bietet als die Unterklasse, wird diese einige Funktionen nicht unterstützen, wodurch dieses Prinzip verletzt wird.

Hier ist ein Codeabschnitt, der gegen das LSP verstößt.

Die Methode area(Rectangle r) berechnet die Fläche des Rechtecks. Das Programm wird nach der Ausführung von Square abstürzen, da Square hier kein Rechteck ist. Laut LSP müssen Funktionen, die Referenzen auf Basisklassen verwenden, in der Lage sein, auch Objekte von abgeleiteten Klassen ohne zusätzliche Anweisungen zu verwenden.

Dieses Prinzip, das eine spezifische Definition des Subtyps ist, wurde 1987 von Barbara Liskov in einem Hauptvortrag auf einer Konferenz mit dem Titel „Datenabstraktion und Hierarchie“ vorgeschlagen – daher der Name.

Das Prinzip der Trennung der Schnittstelle (ISP)

Ein weiteres SOLID-Prinzip. Es besagt, dass eine Schnittstelle, die nicht verwendet wird, nicht implementiert werden sollte. Dieses Prinzip zu befolgen hilft, das System flexibel zu halten und für Refactoring geeignet, wenn Änderungen an der Logik vorgenommen werden.

Diese Situation tritt häufig auf, wenn eine Schnittstelle mehrere Funktionalitäten enthält und der Kunde nur eine davon benötigt.

Da das Schreiben einer Schnittstelle eine komplexe Aufgabe ist, wird es ein Problem sein, sie nach Abschluss der Arbeit zu ändern, ohne etwas zu verletzen.

Der Vorteil des ISP-Prinzips in Java ist, dass zuerst alle Methoden implementiert werden müssen, bevor sie von Klassen verwendet werden können. Daher ermöglicht das Prinzip die Reduzierung der Anzahl der Methoden.

Programmierung für Schnittstellen und nicht für Implementierungen

Hier ist alles klar aus dem Titel. Die Anwendung dieses Prinzips führt zur Schaffung flexibler Codes, die mit jeder neuen Implementierung der Schnittstelle arbeiten können.

Es sollte der Schnittstellentyp für Variablen, Rückgabetypen oder den Argumenttyp der Methode verwendet werden. Beispiel — Verwendung von SuperClass anstelle von SubClass.

Das heißt:

List numbers = getNumbers();

Nicht:

ArrayList numbers = getNumbers();

Hier ist die praktische Umsetzung dessen, was oben erwähnt wurde.

Das Delegierungsprinzip

Ein verbreitetes Beispiel sind die Methoden equals() und hashCode() in Java. Wenn zwei Objekte verglichen werden müssen, wird diese Aktion der entsprechenden Klasse und nicht dem Client überlassen.

Der Vorteil des Prinzips ist die Vermeidung von Code-Duplikation und die relativ einfache Änderung des Verhaltens. Es ist auch auf die Ereignisdelegierung anwendbar.

Alle diese Prinzipien ermöglichen es, flexibleren, schöneren und zuverlässigeren Code mit hoher Kohäsion und niedriger Kopplung zu schreiben. Natürlich ist Theorie gut, aber damit der Entwickler das erworbene Wissen tatsächlich anwendet, ist Praxis erforderlich. Der nächste Schritt nach dem Verständnis der OOP-Prinzipien könnte das Studium von Designmustern zur Lösung allgemeiner Softwareentwicklungsprobleme sein.

Skillbox empfiehlt:

• Praktischer Kurs „Mobiler Entwickler PRO“.
• Angewandter Online-Kurs „Datenanalytiker mit Python“.
• Zweijähriger praktischer Kurs „Ich bin Webentwickler PRO“.

Quelle: habr.com