{"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\/news\/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 ziemlich oft 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 von objektorientierter Programmierung (OOP), oder sie haben davon geh\u00f6rt, verwenden sie aber nicht in der Praxis. In diesem Artikel werden die Vorteile der OOP-Prinzipien beschrieben, die Entwicklern in ihrer t\u00e4glichen Arbeit helfen. Einige davon sind gut bekannt, andere weniger, sodass der Artikel sowohl f\u00fcr Neulinge als auch f\u00fcr erfahrene Programmierer n\u00fctzlich sein wird.
\n<\/a><\/noindex><\/p>\n

Wir erinnern daran:<\/b> f\u00fcr alle Leser von \u201eHabr\u201c \u2014 10.000 Rubel Rabatt bei der Buchung eines beliebigen Skillbox-Kurses mit dem Promo-Code \u201eHabr\u201c.<\/i><\/p>\n

Skillbox empfiehlt:<\/b> Online-Kurs \u201eJava-Entwickler\u201c<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

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

\nEin ziemlich einfaches Prinzip, dessen Wesensart aus dem Namen klar ist: \u201eWiederhole dich nicht\u201c. F\u00fcr Programmierer bedeutet dies, dass dualer Code vermieden werden sollte, und auch die M\u00f6glichkeit gegeben sein muss, Abstraktionen im Arbeitsprozess zu nutzen.<\/p>\n

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

Das ist notwendig, um den Code zu vereinfachen und seine Wartung zu erleichtern, was das Hauptziel der OOP ist. Man sollte jedoch nicht \u00fcbertreiben, da derselbe Code nicht sowohl mit OrderId als auch mit SSN bestehen kann.<\/p>\n

Kapselung von \u00c4nderungen<\/h3>\n

\nSoftwareprodukte der meisten Unternehmen entwickeln sich st\u00e4ndig weiter. Das bedeutet, dass \u00c4nderungen am Code vorgenommen werden m\u00fcssen und er gewartet werden muss. Man kann sich das Leben durch Kapselung erleichtern. Dies erm\u00f6glicht eine effizientere Testung und Wartung des bestehenden Codes. Hier ist eines der Beispiele<\/a><\/noindex>.<\/p>\n

Wenn Sie in Java programmieren, dann weiser Methoden und Variablen standardm\u00e4\u00dfig private zu<\/a><\/noindex>.<\/p>\n

Prinzip der Offenheit\/Abgeschlossenheit<\/h3>\n

\nDieses Prinzip l\u00e4sst sich leicht merken, wenn man die folgende Aussage liest: \u201eSoftwareeinheiten (Klassen, Module, Funktionen usw.) sollten f\u00fcr Erweiterungen offen, aber f\u00fcr \u00c4nderungen geschlossen sein.\u201c Praktisch bedeutet dies, dass sie es erm\u00f6glichen sollten, ihr Verhalten zu \u00e4ndern, ohne den Quellcode zu ver\u00e4ndern.<\/p>\n

Das Prinzip ist wichtig, wenn \u00c4nderungen im Quellcode eine \u00dcberpr\u00fcfung, modulare Tests und andere Verfahren erfordern. Code, der dem Open\/Closed-Prinzip entspricht, wird beim Erweitern nicht ver\u00e4ndert, weshalb es mit ihm viel weniger Probleme gibt.<\/p>\n

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

\"10
\n
\nWenn etwas daran ge\u00e4ndert werden muss, wird dies viel Zeit in Anspruch nehmen, da alle Codeabschnitte, die mit dem relevanten Fragment verbunden sind, ge\u00e4ndert werden m\u00fcssen.<\/p>\n

\u00dcbrigens ist das Open\/Closed-Prinzip eines der SOLID-Prinzipien.<\/p>\n

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

\nEin weiteres Prinzip aus dem SOLID-Set. Es besagt, dass \u201ees nur einen Grund gibt, der zu einer \u00c4nderung der Klasse f\u00fchrt\u201c. Eine Klasse erf\u00fcllt nur eine Aufgabe. Sie kann mehrere Methoden haben, die jedoch alle nur zur L\u00f6sung einer allgemeinen Aufgabe dienen. Alle Methoden und Eigenschaften sollten nur diesem Zweck dienen. <\/p>\n

\"10
\n
\nDer Wert dieses Prinzips liegt darin, dass es die Verbindung zwischen einer einzelnen Softwarekomponente und dem Code schw\u00e4cht. Wenn mehr als eine Funktionalit\u00e4t in eine Klasse eingef\u00fchrt wird, wird eine Verbindung zwischen zwei Funktionen hergestellt. Wenn man also eine von ihnen \u00e4ndert, besteht eine hohe Wahrscheinlichkeit, dass man die zweite, die mit der ersten verbunden ist, besch\u00e4digt. Das bedeutet, dass die Testzyklen erh\u00f6ht werden m\u00fcssen, um alle Probleme im Voraus zu erkennen.<\/p>\n

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

\n\"10
\n
\nDas oben gezeigte Codebeispiel zeigt, dass der AppManager von EventLogWriter abh\u00e4ngt, der wiederum eng mit dem AppManager verbunden ist. Wenn ein anderer Weg ben\u00f6tigt wird, um Benachrichtigungen anzuzeigen, sei es Push, SMS oder E-Mail, muss die Klasse AppManager ge\u00e4ndert werden.<\/p>\n

Das Problem kann mit Hilfe des DIP gel\u00f6st werden. Statt den AppManager zu verwenden, fordern wir den EventLogWriter an, der \u00fcber ein 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\"10Es 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.<\/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 wird Polymorphismus verwendet, der eine flexiblere Implementierung bietet.<\/p>\n

Selbst in \u201eEffective Java\u201c von Joshua Bloch wird empfohlen, die Komposition dem Vererben vorzuziehen.<\/p>\n

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

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

Das LSP h\u00e4ngt sowohl mit dem Prinzip der individuellen Verantwortung als auch mit dem Prinzip der Trennung der Verantwortlichkeiten zusammen. Wenn eine Klasse mehr Funktionalit\u00e4t bietet als die Unterklasse, wird diese einige Funktionen nicht unterst\u00fctzen, wodurch dieses Prinzip verletzt wird.<\/p>\n

Hier ist ein Codeabschnitt, der gegen das LSP verst\u00f6\u00dft.<\/p>\n

\"10
\n
\nDie Methode area(Rectangle r) berechnet die Fl\u00e4che des Rechtecks. Das Programm wird nach der Ausf\u00fchrung von Square abst\u00fcrzen, da Square hier kein Rechteck ist. Laut LSP m\u00fcssen Funktionen, die Referenzen auf Basisklassen verwenden, in der Lage sein, auch Objekte von abgeleiteten Klassen ohne zus\u00e4tzliche Anweisungen zu verwenden.<\/p>\n

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

Das Prinzip der Trennung der Schnittstelle (ISP)<\/h3>\n

\nEin 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\u00fcr Refactoring geeignet, wenn \u00c4nderungen an der Logik vorgenommen werden.<\/p>\n

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

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

Der 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 Reduzierung der Anzahl der Methoden.<\/p>\n

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

Programmierung f\u00fcr Schnittstellen und nicht f\u00fcr Implementierungen<\/h3>\n

\nHier ist alles klar aus dem Titel. Die Anwendung dieses Prinzips f\u00fchrt zur Schaffung flexibler Codes, die mit jeder neuen Implementierung der Schnittstelle arbeiten k\u00f6nnen.<\/p>\n

Es sollte der Schnittstellentyp f\u00fcr Variablen, R\u00fcckgabetypen oder den Argumenttyp der Methode verwendet werden. Beispiel \u2014 Verwendung von SuperClass anstelle von SubClass.<\/p>\n

Das hei\u00dft:<\/p>\n

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

Nicht:<\/p>\n

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

Hier ist die praktische Umsetzung dessen, was oben erw\u00e4hnt wurde.<\/p>\n

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

Das Delegierungsprinzip<\/h3>\n

\nEin verbreitetes Beispiel sind die Methoden equals() und hashCode() in Java. Wenn zwei Objekte verglichen werden m\u00fcssen, wird diese Aktion der entsprechenden Klasse und nicht dem Client \u00fcberlassen.<\/p>\n

Der Vorteil des Prinzips ist die Vermeidung von Code-Duplikation und die relativ einfache \u00c4nderung des Verhaltens. Es ist auch auf die Ereignisdelegierung anwendbar.<\/p>\n

\"10
\n
\nAlle diese Prinzipien erm\u00f6glichen es, flexibleren, sch\u00f6neren und zuverl\u00e4ssigeren Code mit hoher Koh\u00e4sion und niedriger Kopplung zu schreiben. Nat\u00fcrlich ist Theorie gut, aber damit der Entwickler das erworbene Wissen tats\u00e4chlich anwendet, ist Praxis erforderlich. Der n\u00e4chste Schritt nach dem Verst\u00e4ndnis der OOP-Prinzipien k\u00f6nnte das Studium von Designmustern zur L\u00f6sung allgemeiner Softwareentwicklungsprobleme sein.<\/p>\n

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