10 Prinzipien der objektorientierten Programmierung, die jeder Entwickler kennen sollte

Ich treffe häufig auf Entwickler, die noch nie von den SOLID-Prinzipien gehört haben (wir haben ausführlich darüber hier berichtet. — Anm. d. Red.) oder objekorientierter Programmierung (OOP), oder die davon gehört haben, sie aber nicht praktisch anwenden. In diesem Artikel werden die Vorteile der OOP-Prinzipien beschrieben, die Entwicklern in ihrem täglichen Arbeiten helfen. Einige von ihnen sind gut bekannt, andere weniger, sodass der Artikel sowohl für Anfänger als auch für erfahrene Programmierer nützlich sein wird.

Wir erinnern daran: Für alle Leser von "Habr" gibt es einen Rabatt von 10.000 Rubel bei der Anmeldung zu einem beliebigen Kurs von Skillbox mit dem Rabattcode "Habr".

Skillbox empfiehlt: Online-Bildungskurs "Java-Entwickler".

DRY (Don’t Repeat Yourself)

Ein recht einfaches Prinzip, dessen Inhalt sich aus dem Namen ableitet: "Wiederhole dich nicht". Für Programmierer bedeutet das, dass du redundanten Code vermeiden und Abstraktion in der Arbeit nutzen solltest.

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

Dies dient dazu, den Code zu vereinfachen und dessen Wartung zu erleichtern, was das Hauptziel der OOP ist. Man sollte auch nicht übertreiben, denn derselbe Code wird sowohl mit OrderId als auch mit SSN nicht bestehen können.

Kapselung von Änderungen

Die Softwareprodukte der meisten Unternehmen unterliegen ständigen Weiterentwicklungen. Das bedeutet, dass Änderungen am Code vorgenommen und dieser gewartet werden muss. Die Kapselung kann hierbei helfen, das Leben zu erleichtern. Sie ermöglicht eine effizientere Testung und Wartung des bestehenden Codes. Hier ist ein Beispiel.

Wenn Sie in Java programmieren, weisen Sie Methoden und Variablen standardmäßig als privat zu.

Prinzip der Offenheit/Schließung

Dieses Prinzip lässt sich leicht merken, wenn Sie die folgende Aussage lesen: „Programmierobjekte (Klassen, Module, Funktionen usw.) sollten offen für Erweiterungen, aber geschlossen für Änderungen sein.“ In der Praxis bedeutet dies, dass sie ihr Verhalten ändern können, ohne den Quellcode zu modifizieren.

Das Prinzip ist wichtig, wenn Änderungen am Quellcode eine Überarbeitung, Modultests und andere Verfahren erfordern. Code, der dem Prinzip der Offenheit/Schließung folgt, verändert sich nicht bei Erweiterungen, daher gibt es damit wesentlich weniger Probleme.

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

Wenn Änderungen erforderlich sind, kann dies viel Zeit in Anspruch nehmen, da alle Codeteile angepasst werden müssen, die mit dem fraglichen Abschnitt verbunden sind.

Übrigens ist das Prinzip der Offenheit/Schließung eines der SOLID-Prinzipien.

Das Prinzip der einzelnen Verantwortung (SRP)

Ein weiteres Prinzip aus der SOLID-Gruppe. Es besagt, dass "es nur einen Grund gibt, warum eine Klasse geändert werden sollte." Eine Klasse hat nur eine Aufgabe. Sie kann mehrere Methoden haben, aber jede dient nur zur Lösung einer gemeinsamen Aufgabe. Alle Methoden und Eigenschaften sollten ausschließlich diesem Zweck dienen.

Der Wert dieses Prinzips besteht darin, dass es die Verbindung zwischen einer einzelnen Softwarekomponente und dem Code schwächt. Wenn mehr als eine Funktionalität in eine Klasse eingefügt wird, entsteht eine Verbindung zwischen den beiden Funktionen. Wenn eine von ihnen geändert wird, besteht eine große Wahrscheinlichkeit, dass die zweite, die mit der ersten verbunden ist, beeinträchtigt wird. Das bedeutet eine Erhöhung der Testzyklen, um alle Probleme im Voraus zu identifizieren.

Prinzip der Abhängigkeitsinversion (DIP)

Oben finden Sie ein Codebeispiel, in dem der AppManager vom EventLogWriter abhängt, der wiederum eng mit dem AppManager verbunden ist. Wenn eine andere Möglichkeit zur Anzeige einer Benachrichtigung erforderlich ist, sei es Push, SMS oder E-Mail, muss die Klasse AppManager geändert werden.

Das Problem kann mit DIP gelöst werden. Statt den AppManager anzufordern, fragen wir den EventLogWriter an, der über das 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

Die beiden Hauptmethoden zur Wiederverwendung von Code sind Vererbung und Komposition, wobei jede sowohl Vorteile als auch Nachteile hat. Üblicherweise wird der zweiten Methode der Vorzug gegeben, da sie 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 kommt Polymorphie zur Anwendung, die eine flexiblere Umsetzung ermöglicht.

Sogar "Effective Java" von Joshua Bloch empfiehlt, der Komposition den Vorzug vor der Vererbung zu geben.

Das Liskov-Substitutionsprinzip (LSP)

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

Das LSP steht sowohl im Zusammenhang mit dem Prinzip der Einzelverantwortung als auch mit dem Prinzip der Aufteilung der Verantwortung. Wenn eine Klasse mehr Funktionalität bietet als die Unterklasse, wird diese einige Funktionen nicht unterstützen, was dieses Prinzip verletzt.

Hier ist ein Codeabschnitt, der dem LSP widerspricht.

Die Methode area(Rectangle r) berechnet die Fläche eines Rechtecks. Das Programm wird nach der Ausführung von Square abgebrochen, da Square hier kein Rechteck ist. Laut dem Liskov’schen Substitutionsprinzip sollten Funktionen, die Referenzen auf Basisklassen verwenden, in der Lage sein, auch Objekte abgeleiteter Klassen ohne zusätzliche Anweisungen zu verwenden.

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

Prinzip der Schnittstellentrennung (ISP)

Ein weiterer SOLID-Prinzip. Demnach sollte eine nicht verwendete Schnittstelle nicht implementiert werden. Die Einhaltung dieses Prinzips hilft dem System, flexibel zu bleiben und eine einfache Refaktorisierung bei Änderungen an den Arbeitslogiken zu ermöglichen.

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

Da das Schreiben einer Schnittstelle eine komplexe Aufgabe ist, wird es problematisch sein, sie nach Abschluss der Arbeit zu ändern, ohne etwas zu stören.

Ein 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 Anzahl der Methoden zu reduzieren.

Programmierung für das Interface, nicht für die Implementierung

Hier ist alles im Namen klar. Die Anwendung dieses Prinzips führt zur Erstellung flexibler Codes, der mit jeder neuen Implementierung des Interfaces arbeiten kann.

Es sollte der Typ des Interfaces für Variablen, Rückgabetypen oder den Argumenttyp einer Methode verwendet werden. Beispiel – Verwendung von SuperClass und nicht von SubClass.

Das bedeutet:

List numbers = getNumbers();

Nicht:

ArrayList numbers = getNumbers();

Hier ist eine praktische Umsetzung dessen, was oben beschrieben wurde.

Das Delegationsprinzip

Ein verbreitetes Beispiel sind die Methoden equals() und hashCode() in Java. Wenn zwei Objekte verglichen werden sollen, wird diese Aktion an die entsprechende Klasse delegiert, anstatt an die Clientklasse.

Ein Vorteil des Prinzips besteht darin, dass Code-Duplizierung vermieden wird und das Verhalten relativ einfach geändert werden kann. Es ist auch auf die Delegierung von Ereignissen anwendbar.

All diese Prinzipien ermöglichen es, flexibleren, schöneren und zuverlässigeren Code mit hoher Kohäsion und geringem Coupling zu schreiben. Natürlich ist die Theorie wichtig, aber um sicherzustellen, dass ein Entwickler die erworbenen Kenntnisse tatsächlich anwendet, ist praktische Erfahrung erforderlich. Der nächste Schritt nach dem Erlernen der OOP-Prinzipien könnte das Studium von Entwurfsmustern sein, um häufige Softwareentwicklungsprobleme zu lösen.

Skillbox empfiehlt:

• Praktischer Kurs „Mobile Entwickler PRO“.
• Angewandter Online-Kurs Datenanalyst mit Python.
• Zweijähriger praktischer Kurs "Ich bin PRO Web-Entwickler".

Quelle: habr.com