Sehr oft treffe ich Entwickler, die noch nichts von den SOLID-Prinzipien gehört haben (wir . – Übers.) oder objektorientierte Programmierung (OOP) oder haben davon gehört, wenden sie aber nicht in der Praxis an. Dieser Artikel beschreibt die Vorteile von OOP-Prinzipien, die dem Entwickler bei seiner täglichen Arbeit helfen. Einige davon sind bekannt, andere weniger, sodass der Artikel sowohl für Anfänger als auch für erfahrene Programmierer nützlich sein wird.
Erinnerung: Für alle Habr-Leser – 10 Rubel Rabatt bei der Anmeldung zu einem beliebigen Skillbox-Kurs mit dem Habr-Aktionscode.
Skillbox empfiehlt: Pädagogischer Online-Kurs .
DRY (Wiederhole dich nicht)
Ein ziemlich einfaches Prinzip, dessen Kern bereits aus dem Namen hervorgeht: „Wiederholen Sie sich nicht.“ Für einen Programmierer bedeutet dies die Notwendigkeit, doppelten Code zu vermeiden und die Möglichkeit zu haben, Abstraktion in seiner Arbeit zu verwenden.
Wenn der Code zwei sich wiederholende Abschnitte enthält, sollten diese in einer Methode zusammengefasst werden. Wenn ein fest codierter Wert mehr als einmal verwendet wird, lohnt es sich, ihn in eine öffentliche Konstante umzuwandeln.
Dies ist notwendig, um den Code zu vereinfachen und die Wartung zu erleichtern, was das Hauptziel von OOP ist. Sie sollten die Union auch nicht übermäßig verwenden, da derselbe Code die Überprüfung sowohl mit der OrderId als auch mit der SSN nicht besteht.
Kapselung von Änderungen
Die Softwareprodukte der meisten Unternehmen entwickeln sich ständig weiter. Das bedeutet, dass Änderungen am Code vorgenommen werden müssen und dieser unterstützt werden muss. Mit der Kapselung können Sie sich das Leben erleichtern. Dadurch können Sie Ihre vorhandene Codebasis effizienter testen und warten. .
Wenn Sie in Java schreiben, dann .
Offen/geschlossen-Prinzip
Dieses Prinzip kann man sich leicht merken, wenn man die folgende Aussage liest: „Software-Entitäten (Klassen, Module, Funktionen usw.) sollten für Erweiterungen offen, aber für Änderungen geschlossen sein.“ In der Praxis bedeutet dies, dass sie eine Verhaltensänderung zulassen können, ohne den Quellcode zu ändern.
Das Prinzip ist wichtig, wenn Änderungen am Quellcode eine Codeüberarbeitung, Unit-Tests und andere Verfahren erfordern. Code, der dem Offen/Geschlossen-Prinzip folgt, ändert sich bei der Erweiterung nicht, daher gibt es weitaus weniger Probleme damit.
Hier ist ein Beispiel für Code, der gegen dieses Prinzip verstößt.
Wenn Sie darin etwas ändern müssen, wird dies viel Zeit in Anspruch nehmen, da alle Abschnitte des Codes, die mit dem gewünschten Fragment in Verbindung stehen, geändert werden müssen.
Offenheit-Geschlossenheit ist übrigens eines der Prinzipien von SOLID.
Single-Responsibility-Prinzip (SRP)
Ein weiteres Prinzip aus dem SOLID-Set. Darin heißt es: „Es gibt nur eine Ursache, die einen Klassenwechsel verursacht.“ Die Klasse löst nur ein Problem. Es kann mehrere Methoden geben, aber jede davon wird nur zur Lösung eines gemeinsamen Problems verwendet. Alle Methoden und Eigenschaften sollten nur diesem Zweck dienen.
Der Wert dieses Prinzips besteht darin, dass es die Kopplung zwischen der einzelnen Softwarekomponente und dem Code lockert. Wenn Sie einer Klasse mehr als eine Funktionalität hinzufügen, wird eine Beziehung zwischen den beiden Funktionen eingeführt. Wenn Sie also eines davon ändern, besteht eine hohe Wahrscheinlichkeit, dass das zweite, das mit dem ersten verbunden ist, zerstört wird. Und das bedeutet, die Testzyklen zu erhöhen, um alle Probleme im Voraus zu erkennen.
Abhängigkeitsinversionsprinzip (DIP)
Oben sehen Sie ein Codebeispiel, bei dem AppManager von EventLogWriter abhängt, der wiederum eng mit AppManager gekoppelt ist. Wenn Sie eine andere Möglichkeit zum Anzeigen einer Benachrichtigung benötigen, sei es Push, SMS oder E-Mail, müssen Sie die AppManager-Klasse ändern.
Das Problem kann mit DIP gelöst werden. Anstelle von AppManager fordern wir also einen EventLogWriter an, der über das Framework eingegeben wird.
DIP ermöglicht den einfachen Austausch einzelner Module durch andere, indem das Abhängigkeitsmodul geändert wird. Dadurch ist es möglich, ein Modul zu ändern, ohne dass sich dies auf die anderen auswirkt.
Komposition statt Vererbung
Es gibt zwei Hauptmethoden zur Wiederverwendung von Code: Vererbung und Zusammensetzung, die beide ihre eigenen Vor- und Nachteile haben. Normalerweise wird die zweite Variante bevorzugt, da sie flexibler ist.
Composition gibt Ihnen die Möglichkeit, das Verhalten einer Klasse zur Laufzeit zu ändern, indem Sie ihre Eigenschaften festlegen. Bei der Implementierung von Schnittstellen wird Polymorphismus verwendet, was eine flexiblere Implementierung ermöglicht.
Even Effective Java von Joshua Bloch rät dazu, Komposition statt Vererbung zu wählen.
Barbara-Liskov-Substitutionsprinzip (LSP)
Ein weiteres Prinzip aus dem SOLID-Toolkit. Es besagt, dass Subtypen für den Supertyp ersetzbar sein müssen. Das heißt, Methoden und Funktionen, die mit einer Oberklasse arbeiten, sollten problemlos mit ihren Unterklassen zusammenarbeiten können.
LSP ist sowohl mit dem Prinzip der Einzelverantwortung als auch mit dem Prinzip der geteilten Verantwortung verbunden. Wenn eine Klasse mehr Funktionalität bietet als eine Unterklasse, unterstützt diese einen Teil der Funktionalität nicht und verstößt damit gegen dieses Prinzip.
Hier ist ein Code, der LSP widerspricht.
Die Methode „area(Rectangle r)“ berechnet die Fläche eines Rechtecks. Das Programm stürzt nach der Ausführung von Square ab, da Square hier kein Rechteck ist. Nach dem LSP-Prinzip sollen Funktionen, die Referenzen auf Basisklassen verwenden, in der Lage sein, Objekte abgeleiteter Klassen ohne zusätzliche Anweisungen zu verwenden.
Dieses Prinzip, bei dem es sich um eine spezifische Definition eines Subtyps handelt, wurde 1987 von Barbara Liskov in einer Keynote auf der Konferenz mit dem Titel „Datenabstraktion und Hierarchie“ vorgeschlagen, daher der Name.
Prinzip der Schnittstellentrennung (ISP)
Ein weiteres SOLID-Prinzip. Demnach soll eine nicht genutzte Schnittstelle nicht implementiert werden. Durch die Befolgung dieses Prinzips bleibt das System flexibel und für ein Refactoring geeignet, wenn Änderungen an der Betriebslogik vorgenommen werden.
Am häufigsten tritt diese Situation auf, wenn die Schnittstelle mehrere Funktionen gleichzeitig enthält und der Client nur eine davon benötigt.
Da das Schreiben einer Schnittstelle eine schwierige Aufgabe ist, wird es eine Herausforderung sein, sie nach Abschluss der Arbeit zu ändern, ohne dass etwas kaputt geht.
Der Vorteil des ISP-Prinzips in Java besteht darin, dass alle Methoden zuerst implementiert werden müssen und erst dann von Klassen verwendet werden können. Das Prinzip ermöglicht es daher, die Anzahl der Methoden zu reduzieren.
Programmierung für die Schnittstelle, nicht für die Implementierung
Hier geht alles aus dem Titel hervor. Die Anwendung dieses Prinzips führt zur Erstellung flexiblen Codes, der mit jeder neuen Implementierung der Schnittstelle funktionieren kann.
Sie sollten den Schnittstellentyp für Variablen, Rückgabetypen oder den Methodenargumenttyp verwenden. Ein Beispiel ist die Verwendung von SuperClass anstelle von SubClass.
D.h:
Listennummern= getNumbers();
Und nicht:
ArrayList-Zahlen = getNumbers();
Hier ist eine praktische Umsetzung dessen, was oben besprochen wurde.
Delegationsprinzip
Ein häufiges Beispiel sind die Methoden equal() und hashCode() in Java. Wenn es notwendig ist, zwei Objekte zu vergleichen, wird diese Aktion an die entsprechende Klasse statt an die Client-Klasse delegiert.
Der Vorteil des Prinzips besteht darin, dass es keine Duplizierung des Codes gibt und es relativ einfach ist, das Verhalten zu ändern. Dies gilt auch für die Delegation von Veranstaltungen.
All diese Prinzipien ermöglichen es Ihnen, flexibleren, schöneren und zuverlässigeren Code mit hoher Kohäsion und geringer Kopplung zu schreiben. Natürlich ist Theorie gut, aber damit ein Entwickler das erworbene Wissen tatsächlich anwenden kann, bedarf es der Praxis. Sobald Sie die OOP-Prinzipien beherrschen, besteht Ihr nächster Schritt möglicherweise darin, Entwurfsmuster zu erlernen, um häufig auftretende Softwareentwicklungsprobleme zu lösen.
Skillbox empfiehlt:
- Praktischer Kurs .
- Angewandter Online-Kurs .
- Zweijähriges Praktikum .
Source: habr.com