Wie viele Prinzipien gibt es bei Design Patterns?
Categories:
Die ersten zusammengefassten Design Patterns umfassten nur 5, nämlich SOLID:
Single Responsibility Principle (SRP): Eine Klasse sollte nur einen Grund zum Ändern haben, d.h. eine Klasse sollte nur eine Verantwortung tragen.Open/Closed Principle (OCP): Software-Entitäten (Klasse, Modul, Funktion usw.) sollten für Erweiterungen offen, für Modifikationen jedoch geschlossen sein, d.h. Änderungen sollten durch Erweiterungen und nicht durch Änderungen des bestehenden Codes realisiert werden.Liskov Substitution Principle (LSP): Untertypen müssen ihre Basistypen ersetzen können, d.h. abgeleitete Klassen müssen ihre Basisklassen ersetzen können, ohne die Korrektheit des Programms zu beeinträchtigen.Interface Segregation Principle (ISP): Clients sollten nicht gezwungen werden, von Schnittstellen abhängig zu sein, die sie nicht verwenden. Große Schnittstellen sollten in kleinere, spezifischere Schnittstellen unterteilt werden, damit Clients nur die Methoden kennen müssen, die sie verwenden.Dependency Inversion Principle (DIP): Hochrangige Module sollten nicht von niedrigrangigen Modulen abhängen; beide sollten von Abstraktionen abhängen. Abstraktionen sollten nicht von konkreten Implementierungsdetails abhängen; konkrete Implementierungsdetails sollten von Abstraktionen abhängen.
Später kamen zwei weitere Regeln hinzu. Diese später hinzugefügten Regeln sind konkreter und leitender. In den Erklärungen der Prinzipien kann man sehen, dass SOLID beschreibt, was getan werden sollte, während die später hinzugefügten Regeln beschreiben, was vorzuziehen bzw. am besten getan werden sollte.
Composition/Aggregation Reuse Principle (CARP): Die Wiederverwendung von Code sollte vorrangig durch Objektkomposition (Aggregation) und nicht durch Vererbung erreicht werden.Law of Demeter (LoD): Ein Objekt sollte so wenig wie möglich über andere Objekte wissen, d.h. ein Objekt sollte so wenig wie möglich über die internen Strukturen und Implementierungsdetails anderer Objekte wissen.
Neben den oben genannten gängigen Designprinzipien gibt es noch weitere Designprinzipien, die zwar nicht so bekannt sind wie die vorher erwähnten, jedoch ebenfalls eine wichtige Leitfunktion für Software-Design und -Architektur haben. Die später hinzugefügten Regeln wirken etwas überflüssig, zumindest finde ich sie nicht kontraintuitiv und bedürfen keiner tiefgehenden Analyse.
Principle of Least Knowledge (PoLK): Auch als Erweiterung des Law of Demeter bekannt, besagt dieses Prinzip, dass ein Objekt so wenig wie möglich über andere Objekte wissen sollte. Die Entstehung dieses Prinzips lässt sich auf das Jahr 1987 zurückverfolgen, als Patricia Lago und Koos Visser das „Least Communication Law“ vorschlugen.Stable Dependencies Principle (SDP): Dieses Prinzip besagt, dass das Software-Design sicherstellen sollte, dass stabile Komponenten nicht von instabilen Komponenten abhängen, d.h. Komponenten mit höherer Stabilität sollten weniger von Komponenten mit geringerer Stabilität abhängen. Die Gedanken dieses Prinzips stammen aus der tiefgehenden Untersuchung der Beziehungen zwischen Komponenten in Software-Systemen.Stable Abstractions Principle (SAP): In Ergänzung zum Stable Dependencies Principle leitet dieses Prinzip dazu an, Abstraktheit mit Stabilität zu kombinieren, d.h. stabile Komponenten sollten abstrakt und instabile Komponenten sollten konkret sein. Dieses Prinzip hilft dabei, Stabilität und Flexibilität des Software-Systems zu gewährleisten.