{"id":34855,"date":"2019-10-31T22:00:51","date_gmt":"2019-10-31T19:00:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik\/"},"modified":"2019-10-31T22:00:51","modified_gmt":"2019-10-31T19:00:51","slug":"10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 Prinzipien der objektorientierten Programmierung, die jeder Entwickler kennen sollte","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\nIch treffe h\u00e4ufig auf Entwickler, die noch nie von den SOLID-Prinzipien geh\u00f6rt haben (wir haben ausf\u00fchrlich dar\u00fcber hier berichtet<\/a><\/noindex>. \u2014 Anm. d. Red.) oder objekorientierter Programmierung (OOP), oder die davon geh\u00f6rt haben, sie aber nicht praktisch anwenden. In diesem Artikel werden die Vorteile der OOP-Prinzipien beschrieben, die Entwicklern in ihrem t\u00e4glichen Arbeiten helfen. Einige von ihnen sind gut bekannt, andere weniger, sodass der Artikel sowohl f\u00fcr Anf\u00e4nger als auch f\u00fcr erfahrene Programmierer n\u00fctzlich sein wird.
\n<\/a><\/noindex><\/p>\n

Wir erinnern daran:<\/b> F\u00fcr 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\".<\/i><\/p>\n

Skillbox empfiehlt:<\/b> Online-Bildungskurs \"Java-Entwickler\"<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

DRY (Don\u2019t Repeat Yourself)<\/h3>\n

\nEin recht einfaches Prinzip, dessen Inhalt sich aus dem Namen ableitet: \"Wiederhole dich nicht\". F\u00fcr Programmierer bedeutet das, dass du redundanten Code vermeiden und Abstraktion in der Arbeit nutzen solltest.<\/p>\n

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 \u00f6ffentliche Konstante umgewandelt werden.<\/p>\n

Dies dient dazu, den Code zu vereinfachen und dessen Wartung zu erleichtern, was das Hauptziel der OOP ist. Man sollte auch nicht \u00fcbertreiben, denn derselbe Code wird sowohl mit OrderId als auch mit SSN nicht bestehen k\u00f6nnen.<\/p>\n

Kapselung von \u00c4nderungen<\/h3>\n

\nDie Softwareprodukte der meisten Unternehmen unterliegen st\u00e4ndigen Weiterentwicklungen. Das bedeutet, dass \u00c4nderungen am Code vorgenommen und dieser gewartet werden muss. Die Kapselung kann hierbei helfen, das Leben zu erleichtern. Sie erm\u00f6glicht eine effizientere Testung und Wartung des bestehenden Codes. Hier ist ein Beispiel<\/a><\/noindex>.<\/p>\n

Wenn Sie in Java programmieren, weisen Sie Methoden und Variablen standardm\u00e4\u00dfig als privat zu<\/a><\/noindex>.<\/p>\n

Prinzip der Offenheit\/Schlie\u00dfung<\/h3>\n

\nDieses Prinzip l\u00e4sst sich leicht merken, wenn Sie die folgende Aussage lesen: \u201eProgrammierobjekte (Klassen, Module, Funktionen usw.) sollten offen f\u00fcr Erweiterungen, aber geschlossen f\u00fcr \u00c4nderungen sein.\u201c In der Praxis bedeutet dies, dass sie ihr Verhalten \u00e4ndern k\u00f6nnen, ohne den Quellcode zu modifizieren.<\/p>\n

Das Prinzip ist wichtig, wenn \u00c4nderungen am Quellcode eine \u00dcberarbeitung, Modultests und andere Verfahren erfordern. Code, der dem Prinzip der Offenheit\/Schlie\u00dfung folgt, ver\u00e4ndert sich nicht bei Erweiterungen, daher gibt es damit wesentlich weniger Probleme.<\/p>\n

Hier ist ein Beispiel f\u00fcr Code, der dieses Prinzip verletzt.<\/p>\n

\"10
\n
\nWenn \u00c4nderungen erforderlich sind, kann dies viel Zeit in Anspruch nehmen, da alle Codeteile angepasst werden m\u00fcssen, die mit dem fraglichen Abschnitt verbunden sind.<\/p>\n

\u00dcbrigens ist das Prinzip der Offenheit\/Schlie\u00dfung eines der SOLID-Prinzipien.<\/p>\n

Das Prinzip der einzelnen Verantwortung (SRP)<\/h3>\n

\nEin weiteres Prinzip aus der SOLID-Gruppe. Es besagt, dass \"es nur einen Grund gibt, warum eine Klasse ge\u00e4ndert werden sollte.\" Eine Klasse hat nur eine Aufgabe. Sie kann mehrere Methoden haben, aber jede dient nur zur L\u00f6sung einer gemeinsamen Aufgabe. Alle Methoden und Eigenschaften sollten ausschlie\u00dflich diesem Zweck dienen. <\/p>\n

\"10
\n
\nDer Wert dieses Prinzips besteht darin, dass es die Verbindung zwischen einer einzelnen Softwarekomponente und dem Code schw\u00e4cht. Wenn mehr als eine Funktionalit\u00e4t in eine Klasse eingef\u00fcgt wird, entsteht eine Verbindung zwischen den beiden Funktionen. Wenn eine von ihnen ge\u00e4ndert wird, besteht eine gro\u00dfe Wahrscheinlichkeit, dass die zweite, die mit der ersten verbunden ist, beeintr\u00e4chtigt wird. Das bedeutet eine Erh\u00f6hung der Testzyklen, um alle Probleme im Voraus zu identifizieren.<\/p>\n

Prinzip der Abh\u00e4ngigkeitsinversion (DIP)<\/h3>\n

\n\"10
\n
\nOben finden Sie ein Codebeispiel, in dem der AppManager vom EventLogWriter abh\u00e4ngt, der wiederum eng mit dem AppManager verbunden ist. Wenn eine andere M\u00f6glichkeit zur Anzeige einer Benachrichtigung erforderlich ist, sei es Push, SMS oder E-Mail, muss die Klasse AppManager ge\u00e4ndert werden.<\/p>\n

Das Problem kann mit DIP gel\u00f6st werden. Statt den AppManager anzufordern, fragen wir den EventLogWriter an, der \u00fcber das Framework eingef\u00fchrt wird.<\/p>\n

DIP erm\u00f6glicht es, einzelne Module problemlos durch andere zu ersetzen, indem das Abh\u00e4ngigkeitsmodul ge\u00e4ndert wird. Dies erm\u00f6glicht es, ein Modul zu \u00e4ndern, ohne die anderen zu beeinflussen.<\/p>\n

Komposition statt Vererbung<\/h3>\n

\n\"10Die beiden Hauptmethoden zur Wiederverwendung von Code sind Vererbung und Komposition, wobei jede sowohl Vorteile als auch Nachteile hat. \u00dcblicherweise wird der zweiten Methode der Vorzug gegeben, da sie flexibler ist.<\/p>\n

Die Komposition erm\u00f6glicht es, das Verhalten einer Klasse zur Laufzeit durch das Setzen ihrer Eigenschaften zu \u00e4ndern. Bei der Implementierung von Schnittstellen kommt Polymorphie zur Anwendung, die eine flexiblere Umsetzung erm\u00f6glicht.<\/p>\n

Sogar \"Effective Java\" von Joshua Bloch empfiehlt, der Komposition den Vorzug vor der Vererbung zu geben.<\/p>\n

Das Liskov-Substitutionsprinzip (LSP)<\/h3>\n

\nEin weiteres Prinzip aus dem SOLID-Werkzeugkasten. Es besagt, dass Untertypen durch ihren Supertyp ersetzt werden k\u00f6nnen. Das bedeutet, dass Methoden und Funktionen, die mit der Superklasse arbeiten, problemlos auch mit ihren Unterklassen arbeiten sollten.<\/p>\n

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\u00e4t bietet als die Unterklasse, wird diese einige Funktionen nicht unterst\u00fctzen, was dieses Prinzip verletzt.<\/p>\n

Hier ist ein Codeabschnitt, der dem LSP widerspricht.<\/p>\n

\"10
\n
\nDie Methode area(Rectangle r) berechnet die Fl\u00e4che eines Rechtecks. Das Programm wird nach der Ausf\u00fchrung von Square abgebrochen, da Square hier kein Rechteck ist. Laut dem Liskov\u2019schen Substitutionsprinzip sollten Funktionen, die Referenzen auf Basisklassen verwenden, in der Lage sein, auch Objekte abgeleiteter Klassen ohne zus\u00e4tzliche Anweisungen zu verwenden.<\/p>\n

Dieses Prinzip, das eine spezifische Definition eines Subtyps darstellt, wurde 1987 von Barbara Liskov auf einer Konferenz in einem Hauptvortrag mit dem Titel \u201eDatenabstraktion und Hierarchie\u201c vorgestellt \u2013 daher der Name.<\/p>\n

Prinzip der Schnittstellentrennung (ISP)<\/h3>\n

\nEin 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 \u00c4nderungen an den Arbeitslogiken zu erm\u00f6glichen.<\/p>\n

Diese Situation tritt h\u00e4ufig auf, wenn eine Schnittstelle mehrere Funktionen enth\u00e4lt und der Kunde nur eine davon ben\u00f6tigt.<\/p>\n

Da das Schreiben einer Schnittstelle eine komplexe Aufgabe ist, wird es problematisch sein, sie nach Abschluss der Arbeit zu \u00e4ndern, ohne etwas zu st\u00f6ren.<\/p>\n

Ein Vorteil des ISP-Prinzips in Java ist, dass zuerst alle Methoden implementiert werden m\u00fcssen, bevor sie von Klassen verwendet werden k\u00f6nnen. Daher erm\u00f6glicht das Prinzip, die Anzahl der Methoden zu reduzieren.<\/p>\n

\"10
\n <\/p>\n

Programmierung f\u00fcr das Interface, nicht f\u00fcr die Implementierung<\/h3>\n

\nHier ist alles im Namen klar. Die Anwendung dieses Prinzips f\u00fchrt zur Erstellung flexibler Codes, der mit jeder neuen Implementierung des Interfaces arbeiten kann.<\/p>\n

Es sollte der Typ des Interfaces f\u00fcr Variablen, R\u00fcckgabetypen oder den Argumenttyp einer Methode verwendet werden. Beispiel \u2013 Verwendung von SuperClass und nicht von SubClass.<\/p>\n

Das bedeutet:<\/p>\n

List numbers = getNumbers();<\/i><\/p>\n

Nicht:<\/p>\n

ArrayList numbers = getNumbers();<\/i><\/p>\n

Hier ist eine praktische Umsetzung dessen, was oben beschrieben wurde.<\/p>\n

\"10
\n <\/p>\n

Das Delegationsprinzip<\/h3>\n

\nEin 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.<\/p>\n

Ein Vorteil des Prinzips besteht darin, dass Code-Duplizierung vermieden wird und das Verhalten relativ einfach ge\u00e4ndert werden kann. Es ist auch auf die Delegierung von Ereignissen anwendbar.<\/p>\n

\"10
\n
\nAll diese Prinzipien erm\u00f6glichen es, flexibleren, sch\u00f6neren und zuverl\u00e4ssigeren Code mit hoher Koh\u00e4sion und geringem Coupling zu schreiben. Nat\u00fcrlich ist die Theorie wichtig, aber um sicherzustellen, dass ein Entwickler die erworbenen Kenntnisse tats\u00e4chlich anwendet, ist praktische Erfahrung erforderlich. Der n\u00e4chste Schritt nach dem Erlernen der OOP-Prinzipien k\u00f6nnte das Studium von Entwurfsmustern sein, um h\u00e4ufige Softwareentwicklungsprobleme zu l\u00f6sen.<\/p>\n

Skillbox empfiehlt:<\/b><\/p>\n