Gut gemachte Software braucht eine gute Codebasis, die leicht zu lesen, zu verstehen, zu pflegen (Funktionen hinzuf\u00fcgen\/\u00e4ndern, Fehler beheben) und f\u00fcr die Zukunft erweiterbar ist. Das spart Entwicklungszeit und Ressourcen. <\/p>\n
SOLID-Prinzipien des OOP:<\/h2>\n
S<\/strong> – Prinzip der einzigen Verantwortung<\/p>\n O<\/strong> – Offen\/Geschlossen-Prinzip<\/p>\n L<\/strong> – Liskov-Substitutionsprinzip<\/p>\n I<\/strong> – Prinzip der Schnittstellentrennung<\/p>\n D<\/strong> – Prinzip der Inversion von Abh\u00e4ngigkeiten<\/p>\n Das Prinzip der Einzelverantwortung besagt, dass jedes Modul, jede Klasse oder Funktion in einem Computerprogramm f\u00fcr einen Teil der Funktionalit\u00e4t dieses Programms verantwortlich sein sollte. Ebenso sollten sie diesen Teil kapseln, und ihre Dienste sollten eng mit dieser Verantwortung verkn\u00fcpft sein. Dies stellt sicher, dass Klassen kleiner, \u00fcbersichtlicher, leichter verst\u00e4ndlich sind und die Wartung des Codes einfacher ist. Wenn eine Klasse mehrere Aufgaben ausf\u00fchrt, wird sie komplex und fehleranf\u00e4llig. <\/p>\n Beispiele f\u00fcr Verantwortlichkeiten, die in Software im Allgemeinen getrennt werden m\u00fcssen: Formatierung, Parsing, Mapping, Validierung, Protokollierung, Persistenz, Benachrichtigung, Fehlerbehandlung, Klassenauswahl\/Instanz usw.<\/p>\n Das Prinzip der Offenheit und Geschlossenheit besagt, dass Module, Klassen und Funktionen offen f\u00fcr Erweiterungen und geschlossen f\u00fcr \u00c4nderungen sein sollten. Das bedeutet, dass wir in der Lage sein sollten, das Verhalten eines Moduls oder einer Klasse zu \u00e4ndern, ohne deren Quellcode \u00e4ndern zu m\u00fcssen. Dies erreichen wir durch den Einsatz von Schnittstellen, abstrakten Klassen oder Vererbung. Auf diese Weise minimieren wir das Risiko, beim Hinzuf\u00fcgen neuer Funktionen Fehler in den bestehenden Code einzubauen. <\/p>\n F\u00fcgen Sie neue Funktionen hinzu, indem Sie neue abgeleitete Klassen erstellen, die von der urspr\u00fcnglichen Basisklasse erben und dem Client den Zugriff auf die urspr\u00fcngliche Klasse \u00fcber eine abstrakte Schnittstelle mittels kompositorischer Entwurfsmuster wie dem Strategy-Muster<\/em> erm\u00f6glichen. Anstatt die bestehende Funktionalit\u00e4t zu \u00e4ndern, erstelle neue abgeleitete Klassen und lasse die urspr\u00fcngliche Implementierung der Klasse unver\u00e4ndert. Dieses Prinzip wird verletzt, wenn Sie die Basisklasse \u00e4ndern m\u00fcssen. <\/p>\n Das Liskovsche Substitutionsprinzip besagt, dass ein Objekt einer bestimmten Klasse durch eine Instanz seiner abgeleiteten Klassen ersetzt werden k\u00f6nnen sollte, ohne dass sich das Verhalten des Programms \u00e4ndert. Das bedeutet, dass, wenn wir eine Klasse A haben und von dieser eine abgeleitete Klasse B, wir B \u00fcberall dort verwenden k\u00f6nnen sollten, wo wir ein Objekt vom Typ A erwarten. Dieses Prinzip stellt sicher, dass Vererbung und Polymorphismus korrekt und konsistent funktionieren. <\/p>\n Wenn wir ein Objekt bzw. eine Instanz einer Elternklasse erfolgreich durch ein Objekt bzw. eine Instanz einer abgeleiteten Klasse ersetzen k\u00f6nnen, ohne das Verhalten der Instanz der Basisklasse zu beeinflussen, dann halten wir das Liskov Substitutionsprinzip (LSP) ein. Wenn dieses Prinzip verletzt wird, f\u00fchrt dies in der Regel zu vielen zus\u00e4tzlichen bedingten Logiken, die im gesamten Anwendungscode verstreut sind und \u00fcberpr\u00fcfen, ob ein Objekt von einem bestimmten Typ ist. <\/p>\n Mit zunehmender Gr\u00f6\u00dfe der Anwendung wird der duplizierte und verstreute Code zu einer Brutst\u00e4tte f\u00fcr Fehler. Eine sehr h\u00e4ufige Verletzung dieses Prinzips ist die Teilimplementierung von Schnittstellen oder Funktionen der Basisklasse, bei der nicht alle Methoden oder Eigenschaften implementiert werden und stattdessen eine Ausnahme geworfen wird (zum Beispiel NotImplementedException).<\/p>\n Bei Code, von dem Sie wissen, dass er nur von einem einzigen Kunden verwendet wird, den Sie \u00fcberwachen k\u00f6nnen, ist das in Ordnung. Aber im gemeinsam genutzten Code oder noch schlimmer in einem Framework, das an Dritte geliefert wird, sollten solche Implementierungen nicht vorkommen.<\/p>\n Wenn eine Schnittstelle mehr Funktionen hat, als Sie ben\u00f6tigen, verwenden Sie das Prinzip der Schnittstellentrennung (ISP), um eine neue Schnittstelle zu erstellen, die nur die Funktionen enth\u00e4lt, die Ihr Client-Code ben\u00f6tigt und die Sie vollst\u00e4ndig implementieren k\u00f6nnen.<\/p>\n Das Prinzip der Schnittstellentrennung besagt, dass wir eher mehrere spezifische Schnittstellen als eine gro\u00dfe, generische Schnittstelle erstellen sollten. Das hilft uns, Abh\u00e4ngigkeiten zu minimieren und sicherzustellen, dass Klassen nur die Methoden implementieren, die sie ben\u00f6tigen, und nicht gezwungen sind, unn\u00f6tige Methoden zu implementieren. Einfach ausgedr\u00fcckt: Kunden sollten nicht gezwungen werden, Methoden zu implementieren, die sie nicht nutzen. <\/p>\n Das Prinzip der umgekehrten Abh\u00e4ngigkeit besagt, dass Module\/Klassen auf einer h\u00f6heren Ebene nicht von Modulen\/Klassen auf einer niedrigeren Ebene abh\u00e4ngen sollten. Stattdessen sollten beide von Abstraktionen abh\u00e4ngen. Weiterhin sollten Abstraktionen nicht von Implementierungsdetails abh\u00e4ngen; diese Details sollten von Abstraktionen abh\u00e4ngen. <\/p>\n Wenn eine Klasse das Design und die Implementierung einer anderen Klasse kennt, erh\u00f6ht sich das Risiko, dass \u00c4nderungen in einer Klasse die andere Klasse beeintr\u00e4chtigen. Versuche immer, Module\/Klassen auf verschiedenen Ebenen so wenig wie m\u00f6glich miteinander zu verbinden. Um dies zu erreichen, m\u00fcssen wir beide von Abstraktionen abh\u00e4ngig machen, anstatt uns gegenseitig zu kennen. Auf diese Weise erreichen wir, dass der Code flexibel ist und leicht ge\u00e4ndert werden kann, ohne dass Sie alle Stellen \u00e4ndern m\u00fcssen, an denen die Klasse verwendet wird. <\/p>\n Software-Designprinzipien sind Empfehlungen, die Programmierer bei der Erstellung von Software befolgen, um sauberen und nachhaltigen Code zu erzeugen. Es handelt sich um eine Sammlung von Techniken und Best Practices, die von vielen bekannten Experten und Autoren der Branche empfohlen werden. <\/p>\n Die SOLID-Prinzipien der objektorientierten Programmierung stellen einen wichtigen Bestandteil des objektorientierten Softwaredesigns dar. Die Einhaltung dieser Vorgaben hilft uns, hochwertigen, nachhaltigen und leicht erweiterbaren Code zu erstellen. <\/p>\n Das Prinzip der einzigen Verantwortung<\/strong> sorgt daf\u00fcr, dass die Klassen eine einzige Verantwortung haben. Beherrscht du die SOLID-Prinzipien und die Programmiersprache Java<\/a>? Wenn du zum Beispiel einen Job suchst. als Java-Programmierer<\/a>, siehe dir unsere Mitarbeiterbenefits <\/a>an und reagiere auf die neuesten Stellenangebote<\/a>. <\/p>\n","protected":false},"excerpt":{"rendered":" Bei den SOLID-Prinzipien handelt es sich um eine Reihe von f\u00fcnf Grundprinzipien der objektorientierten Programmierung (OOP), die dazu beitragen, qualitativ hochwertige und hoch skalierbare Software zu erstellen.<\/p>\n","protected":false},"author":14,"featured_media":4175,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[62],"tags":[],"class_list":["post-4172","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-java"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/posts\/4172","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/users\/14"}],"replies":[{"embeddable":true,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/comments?post=4172"}],"version-history":[{"count":5,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/posts\/4172\/revisions"}],"predecessor-version":[{"id":9339,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/posts\/4172\/revisions\/9339"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/media\/4175"}],"wp:attachment":[{"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/media?parent=4172"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/categories?post=4172"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/msgprogramator.sk\/de\/wp-json\/wp\/v2\/tags?post=4172"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Single Responsibility Principle (SRP) – Prinzip der einzigen Verantwortung<\/h2>\n
Open\/Closed Principle (OCP) – Prinzip der Offenheit und Geschlossenheit<\/h2>\n
Wie Sie OCP anwenden:<\/h3>\n
Liskov Substitution Principle (LSP) – Das Liskovsche Substitutionsprinzip<\/h2>\n
![\"Solche](\"https:\/\/msgprogramator.sk\/wp-content\/uploads\/2023\/10\/solid-aplikovanie-principov-1200-800.webp\")
Interface Segregation Principle (ISP) – Prinzip der Schnittstellentrennung<\/h2>\n
Dependency Inversion Principle (DIP) – Prinzip der Abh\u00e4ngigkeitsumkehr<\/h2>\n
Fazit<\/h2>\n
\nDas Open\/Closed-Prinzip<\/strong> erm\u00f6glicht es uns, das Verhalten von Klassen zu \u00e4ndern, ohne den Code zu modifizieren.
\nDas Liskov-Substitutionsprinzip<\/strong> stellt sicher, dass abgeleitete Klassen anstelle der \u00fcbergeordneten Klasse verwendet werden k\u00f6nnen. Das Prinzip der Schnittstellentrennung<\/strong> hilft uns, die Abh\u00e4ngigkeiten zwischen Klassen zu minimieren.
\nDas Prinzip der Inversion von Abh\u00e4ngigkeiten<\/strong> stellt sicher, dass wir von Abstraktionen und nicht von konkreten Implementierungen abh\u00e4ngig sind.<\/p>\n