Ich stoße ziemlich oft auf Entwickler, die nicht von den Prinzipien von SOLID gehört haben (wir
haben hier ausführlich darüber gesprochen . - Transl.) Oder objektorientierte Programmierung (OOP) oder gehört haben, sie aber in der Praxis nicht verwenden. Dieser Artikel beschreibt die Vorteile von OOP-Prinzipien, die einem Entwickler bei seiner täglichen Arbeit helfen. Einige von ihnen sind bekannt, andere nicht sehr gut, so dass der Artikel sowohl für Anfänger als auch für erfahrene Programmierer nützlich sein wird.
Wir erinnern Sie daran: Für alle Leser von „Habr“ - ein Rabatt von 10.000 Rubel bei der Anmeldung für einen Skillbox-Kurs mit dem Promo-Code „Habr“.
Skillbox empfiehlt: Der Java Developer Online Education-Kurs.
TROCKEN (Wiederholen Sie sich nicht)
Ein ziemlich einfaches Prinzip, dessen Wesen aus dem Titel hervorgeht: "Nicht wiederholen." Für den Programmierer bedeutet dies die Notwendigkeit, doppelten Code zu vermeiden sowie die Möglichkeit, Abstraktion in der Arbeit zu verwenden.
Wenn der Code zwei sich wiederholende Abschnitte enthält, sollten diese zu einer Methode kombiniert werden. Wenn ein fest codierter Wert mehrmals verwendet wird, lohnt es sich, ihn in eine öffentliche Konstante umzuwandeln.
Dies ist erforderlich, um den Code zu vereinfachen und seine Unterstützung zu vereinfachen. Dies ist die Hauptaufgabe von OOP. Das Kombinieren der Union lohnt sich ebenfalls nicht, da derselbe Code die Überprüfung sowohl mit OrderId als auch mit SSN nicht besteht.
Verkapselung von Veränderungen
Die Softwareprodukte der meisten Unternehmen werden ständig weiterentwickelt. Sie müssen also Änderungen am Code vornehmen, er muss unterstützt werden. Sie können Ihr Leben durch Einkapselung vereinfachen. Dies ermöglicht ein effizienteres Testen und Warten der vorhandenen Codebasis.
Hier ist ein Beispiel .
Wenn Sie in Java schreiben,
weisen Sie standardmäßig private Methoden und Variablen zu .
Das Prinzip der Offenheit / Nähe
An dieses Prinzip kann man sich leicht erinnern, wenn man die folgende Aussage liest: "Software-Entitäten (Klassen, Module, Funktionen usw.) müssen für Erweiterungen geöffnet, für Änderungen jedoch geschlossen sein." In der Praxis bedeutet dies, dass Sie ihr Verhalten ändern können, ohne den Quellcode zu ändern.
Das Prinzip ist wichtig, wenn Änderungen am Quellcode eine Überarbeitung, Unit-Tests und andere Verfahren erfordern. Code, der dem Prinzip der Offenheit / Nähe folgt, ändert sich während der Erweiterung nicht, sodass es viel weniger Probleme gibt.
Hier ist ein Beispiel für Code, der gegen dieses Prinzip verstößt.
Wenn Sie etwas daran ändern müssen, wird dies viel Zeit in Anspruch nehmen, da Sie alle Abschnitte des Codes ändern müssen, die eine Verbindung mit dem gewünschten Fragment haben.
Offenheit ist übrigens eines der Prinzipien von SOLID.
Prinzip der Einzelverantwortung (SRP)
Ein weiteres Prinzip aus der SOLID Suite. Er gibt an, dass "es nur einen Grund gibt, der zu einem Klassenwechsel führt." Eine Klasse löst nur ein Problem. Es kann mehrere Methoden geben, aber jede davon wird nur verwendet, um ein allgemeines Problem zu lösen. Alle Methoden und Eigenschaften sollten nur diesem dienen.
Der Wert dieses Prinzips besteht darin, dass es die Verbindung zwischen der einzelnen Softwarekomponente und dem Code schwächt. Wenn Sie einer Klasse mehr als eine Funktionalität hinzufügen, wird eine Verbindung zwischen den beiden Funktionen hergestellt. Wenn Sie also einen von ihnen ändern, besteht eine große Chance, den zweiten, der mit dem ersten verbunden ist, zu verderben. Dies bedeutet eine Verlängerung der Testzyklen, um alle Probleme im Voraus zu identifizieren.
Prinzip der Abhängigkeitsinversion (DIP)
Das Obige ist ein Beispielcode, bei dem der AppManager von einem EventLogWriter abhängt, der wiederum eng mit dem AppManager verwandt 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. Daher fordern wir anstelle von AppManager einen EventLogWriter an, der mithilfe des Frameworks eingeführt wird.
Mit DIP können Sie einzelne Module einfach durch andere ersetzen und das Abhängigkeitsmodul ändern. Dies ermöglicht es, ein Modul zu wechseln, ohne den Rest zu beeinflussen.
Zusammensetzung statt Vererbung
Es gibt zwei Möglichkeiten, Code wiederzuverwenden: Vererbung und Zusammensetzung. Jede hat ihre eigenen Vor- und Nachteile. Die zweite wird normalerweise bevorzugt, weil sie flexibler ist.
Mit Composition können Sie das Verhalten einer Klasse zur Laufzeit ändern, indem Sie ihre Eigenschaften festlegen. Bei der Implementierung von Schnittstellen wird Polymorphismus verwendet, was eine flexiblere Implementierung ermöglicht.
Sogar "Effective Java" von Joshua Bloch rät dazu, der Komposition den Vorzug vor der Vererbung zu geben.
Barbara-Lisk-Substitutionsprinzip (LSP)
Ein weiteres Prinzip aus dem SOLID Toolkit. Es besagt, dass Subtypen für einen Supertyp austauschbar sein müssen. Das heißt, Methoden und Funktionen, die mit einer Oberklasse arbeiten, sollten problemlos mit ihren Unterklassen arbeiten können.
LSP ist sowohl mit dem Prinzip der Einzelverantwortung als auch mit dem Prinzip der Aufteilung der Verantwortung verbunden. Wenn eine Klasse mehr Funktionen als eine Unterklasse bietet, unterstützt diese einige Funktionen nicht, was gegen dieses Prinzip verstößt.
Hier ist ein Code, der dem LSP widerspricht.
Die Flächenmethode (Rechteck r) berechnet die Fläche des Rechtecks. Das Programm stürzt nach der Ausführung von Square ab, da Square hier kein Rechteck ist. Nach dem LSP-Prinzip sollten Funktionen, die Verweise auf Basisklassen verwenden, Objekte abgeleiteter Klassen ohne zusätzliche Anweisungen verwenden können.
Dieses Prinzip, das eine spezifische Definition eines Subtyps darstellt, wurde 1987 von Barbara Liskov auf einer Konferenz im Hauptbericht mit dem Titel „Datenabstraktion und Hierarchie“ vorgeschlagen - daher der Name.
Prinzip der Schnittstellentrennung (ISP)
Ein weiteres SOLID-Prinzip. Ihm zufolge sollte eine Schnittstelle, die nicht verwendet wird, nicht implementiert werden. Das Befolgen dieses Prinzips hilft dem System, flexibel und für das Refactoring geeignet zu bleiben, wenn Änderungen an der Arbeitslogik vorgenommen werden.
In den meisten Fällen tritt diese Situation auf, wenn die Schnittstelle mehrere Funktionen gleichzeitig enthält und der Client nur eine davon benötigt.
Da das Schreiben einer Benutzeroberfläche eine schwierige Aufgabe ist, ist es nach Abschluss der Arbeiten ein Problem, sie zu ändern, ohne etwas zu beschädigen.
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 eine Schnittstelle, keine Implementierung
Alles hier ist aus dem Namen klar. Die Anwendung dieses Prinzips führt zur Erstellung von flexiblem Code, der mit jeder neuen Schnittstellenimplementierung funktioniert.
Verwenden Sie den Schnittstellentyp für Variablen, Rückgabetypen oder den Typ des Methodenarguments. Ein Beispiel ist die Verwendung von SuperClass, nicht von SubClass.
Also:
Listennummern = getNumbers ();Und nicht:
ArrayList numbers = getNumbers ();Hier ist eine praktische Implementierung dessen, was oben gesagt wurde.
Delegationsprinzip
Ein häufiges Beispiel sind die Methoden equals () und hashCode () in Java. Wenn zwei Objekte verglichen werden müssen, wird diese Aktion anstelle des Clients an die entsprechende Klasse delegiert.
Ein Vorteil des Prinzips ist das Fehlen von Codeduplizierungen und eine relativ einfache Verhaltensänderung. Dies gilt auch für die Delegation von Veranstaltungen.
All diese Prinzipien ermöglichen das Schreiben von flexiblerem, schönerem und zuverlässigerem Code mit hoher Konnektivität und geringem Gang. Natürlich ist die Theorie gut, aber damit der Entwickler das gewonnene Wissen wirklich nutzen kann, ist Übung erforderlich. Der nächste Schritt nach der Beherrschung der Prinzipien von OOP kann das Studium von Entwurfsmustern sein, um allgemeine Probleme der Softwareentwicklung zu lösen.
Skillbox empfiehlt: