Single-Responsibility-Prinzip

Das Single-Responsibility-Prinzip besagt, dass jede Klasse nur eine einzige Verantwortung haben solle. Verantwortung wird hierbei als „Grund zur Änderung“ definiert:

Mehr als eine Verantwortung für eine Klasse führt zu mehreren Bereichen, in denen zukünftige Änderungen notwendig werden können. Die Wahrscheinlichkeit, dass die Klasse zu einem späteren Zeitpunkt geändert werden muss, steigt zusammen mit dem Risiko, sich bei solchen Änderungen subtile Fehler einzuhandeln. Dieses Prinzip führt in der Regel zu Klassen mit hoher Kohäsion, in denen alle Methoden einen starken gemeinsamen Bezug haben.

Open-Closed-Prinzip

Das Open-Closed-Prinzip besagt, dass Software-Einheiten (hier Module, Klassen, Methoden usw.) Erweiterungen möglich machen sollen (dafür offen sein), aber ohne dabei ihr Verhalten zu ändern (ihr Sourcecode und ihre Schnittstelle sollte sich nicht ändern). Es wurde 1988 von Bertrand Meyer folgendermaßen formuliert:

Eine Erweiterung im Sinne des Open-Closed-Prinzips ist beispielsweise die Vererbung. Diese verändert das vorhandene Verhalten einer Klasse nicht, erweitert sie aber um zusätzliche Funktionen oder Daten. Überschriebene Methoden verändern auch nicht das Verhalten der Basisklasse, sondern nur das der abgeleiteten Klasse. Folgt man weiter dem Liskovschen Substitutionsprinzip, verändern auch überschriebene Methoden nicht das Verhalten, sondern nur die Algorithmen.

Liskovsches Substitutionsprinzip

Das Liskovsche Substitutionsprinzip (LSP) oder Ersetzbarkeitsprinzip fordert, dass eine Instanz einer abgeleiteten Klasse sich so verhalten muss, dass jemand, der meint, ein Objekt der Basisklasse vor sich zu haben, nicht durch unerwartetes Verhalten überrascht wird, wenn es sich dabei tatsächlich um ein Objekt eines Subtyps handelt. Es wurde 1993 von Barbara Liskov und Jeannette Wing formuliert. In einem nachfolgenden Artikel wurde es folgendermaßen formuliert:

Damit ist garantiert, dass Operationen vom Typ Superklasse, die auf ein Objekt des Typs Subklasse angewendet werden, auch korrekt ausgeführt werden. Dann lässt sich stets bedenkenlos ein Objekt vom Typ Superklasse durch ein Objekt vom Typ Subklasse ersetzen. Objektorientierte Programmiersprachen können eine Verletzung dieses Prinzips, die aufgrund der mit der Vererbung verbundenen Polymorphie auftreten kann, nicht von vornherein ausschließen. Häufig ist eine Verletzung des Prinzips nicht auf den ersten Blick offensichtlich.

Interface-Segregation-Prinzip

Das Interface-Segregation-Prinzip dient dazu, zu große Interfaces aufzuteilen. Die Aufteilung soll gemäß den Anforderungen der Clients an die Interfaces gemacht werden – und zwar derart, dass die neuen Interfaces genau auf die Anforderungen der einzelnen Clients passen. Die Clients müssen also nur mit Interfaces agieren, die das und nur das können, was die Clients benötigen. Das Prinzip wurde von Robert C. Martin 1996 folgendermaßen formuliert:

Mit Hilfe des Interface-Segregation-Prinzips ist es möglich eine Software derart in entkoppelte und somit leichter refaktorisierbare Klassen aufzuteilen, dass zukünftige fachliche oder technische Anforderungen an die Software nur geringe Änderungen an der Software selbst benötigen.

Dependency-Inversion-Prinzip

Das Dependency-Inversion-Prinzip beschäftigt sich mit der Reduktion der Kopplung von Modulen. Es besagt, dass Abhängigkeiten immer von konkreteren Modulen niedriger Ebenen zu abstrakten Modulen höherer Ebenen gerichtet sein sollten. Es wurde von Robert C. Martin erstmals im Oktober 1994 beschrieben und später folgendermaßen formuliert:

Damit ist sichergestellt, dass die Abhängigkeitsbeziehungen immer in eine Richtung verlaufen, von den konkreten zu den abstrakten Modulen, von den abgeleiteten Klassen zu den Basisklassen. Damit werden die Abhängigkeiten zwischen den Modulen reduziert und insbesondere zyklische Abhängigkeiten vermieden.

Gesetz von Demeter

Das Gesetz von Demeter (englisch: Law of Demeter, kurz: LoD) besagt im Wesentlichen, dass Objekte nur mit Objekten in ihrer unmittelbaren Umgebung kommunizieren sollen. Dadurch soll die Kopplung in einem Softwaresystem verringert und dadurch die Wartbarkeit erhöht werden.

Das Gesetz wurde von Karl J. Lieberherr und Ian Holland 1989 im Paper Assuring Good Style for Object-Oriented Programs folgendermaßen beschrieben:

Durch die formale Spezifikation lässt sich das Gesetz von Demeter leicht als automatisch geprüfte Softwaremetrik umsetzen. Es bietet sich somit zur Früherkennung von Kopplungsproblemen an.

Design by Contract

Das Design-by-contract-Prinzip, englisch für Entwurf gemäß Vertrag, auch Programming by Contract genannt, hat das reibungslose Zusammenspiel einzelner Programmmodule durch die Definition formaler „Verträge“ zur Verwendung von Schnittstellen, die über deren statische Definition hinausgehen zum Ziel. Entwickelt und eingeführt wurde es von Bertrand Meyer mit der Entwicklung der Programmiersprache Eiffel.

Das reibungslose Zusammenspiel der Programmmodule wird durch einen „Vertrag“ erreicht, der beispielsweise bei der Verwendung einer Methode einzuhalten ist. Dieser besteht aus

• Vorbedingungen (englisch precondition), also den Zusicherungen, die der Aufrufer einzuhalten hat
• Nachbedingungen (englisch postcondition), also den Zusicherungen, die der Aufgerufene einhalten wird, sowie den
• Invarianten (englisch class invariants), quasi dem Gesundheitszustand einer Klasse.

Der Einsatz des Design-by-Contract-Prinzips führt zu sicherer und weniger fehleranfälliger Software, da eine Verletzung des Vertrages zu einem sofortigen Fehler (Fail-Fast) bereits in der Softwareentwicklungsphase führt. Weiters kann die explizite Definition des Vertrages als Form der Dokumentation des Verhaltens des entsprechenden Moduls gesehen werden. Das wiederum führt zu einer besseren Erlernbarkeit und Wartbarkeit der Software.

Datenkapselung

Datenkapselung (engl. encapsulation), nach David Parnas auch bekannt als information hiding, ist nach Bertrand Meyer ein weiteres Prinzip objektorientierten Designs. Es beschreibt das Verbergen von Daten oder Informationen vor dem Zugriff von außen. Der direkte Zugriff auf die interne Datenstruktur wird unterbunden und erfolgt stattdessen über definierte Schnittstellen. Die in der Objektorientierung verwendeten Zugriffsarten (private, protected, …) sowie eine Reihe von Entwurfsmustern – beispielsweise Facade – unterstützen bei der Umsetzung der Datenkapselung.

Linguistic-Modular-Units-Prinzip

Das Linguistic-Modular-Units-Prinzip (englisch für Prinzip linguistisch-modularer Einheiten) besagt, dass Module durch syntaktische Einheiten der verwendeten Sprache – sei es eine Programmier-, Design- oder Spezifikationssprache – repräsentiert werden müssen. Im Falle einer Programmiersprache müssen Module durch separat voneinander kompilierbare Einheiten dieser gewählten Programmiersprache repräsentiert werden:

Self-Documentation-Prinzip

Das Self-Documentation-Prinzip (englisch für Selbstdokumentierungsprinzip) besagt, dass alle Informationen zu einem Modul in diesem selbst enthalten sein sollten. Damit wird gefordert, dass der Code entweder selbst für sich spricht (d. h. keine weitere Dokumentation nötig hat) beziehungsweise die technische Dokumentation möglichst nahe beim Sourcecode (beispielsweise bei der Verwendung von Javadoc) liegt. Dadurch wird einerseits gewährleistet, dass die technische Dokumentation dem Code entspricht und andererseits, dass die Komplexität des Codes so gering ist, dass keine komplexe Dokumentation nötig ist:

Uniform-Access-Prinzip

Das Uniform-Access-Prinzip (englisch für Prinzip des gleichartigen Zugriffes) fordert, dass auf alle Services eines Modules mittels einer gleichartigen Notation zugegriffen werden kann – ohne dass dadurch preisgegeben wird, ob die Services dahinter auf Datenbestände zugreifen, oder Berechnungen durchführen. Services sollten also nach außen nicht bekanntgeben, wie sie ihre Serviceleistung erbringen, sondern nur was ihre Serviceleistung ist:

Single-Choice-Prinzip

Das Single-Choice-Prinzip besagt, dass verschiedene Alternativen (beispielsweise von Daten oder Algorithmen) in einem Softwaresystem in nur einem einzigen Modul abgebildet werden sollten. Beispielsweise unterstützt das Entwurfsmuster Abstrakte Fabrik dieses Prinzip, indem in der Fabrik einmal aus einem Set an Alternativen entschieden wird, welche Klassen und welche Algorithmen zu verwenden sind. Diese Entscheidung muss an keiner weiteren Stelle im Programm mehr getroffen werden:

Persistence-Closure-Prinzip

Das Persistence-Closure-Prinzip besagt, dass Persistenzmechanismen Objekte mit all ihren Abhängigkeiten speichern und auch wieder laden müssen. Damit ist sichergestellt, dass Objekte ihre Eigenschaften durch Speichern und darauffolgendes Laden nicht verändern.

Command-Query-Separation-Prinzip

Das Command-Query-Separation-Prinzip (CQS) besagt, dass eine Methode entweder als Abfrage (query) oder als Kommando (command (auch modifier oder mutator genannt)) implementiert werden soll. Eine Abfrage muss hierbei Daten zurückliefern und darf keine Nebeneffekte auf dem beobachtbaren Zustand des Systems aufweisen, während ein Kommando beobachtbare Nebeneffekte aufweist und keine Daten zurückliefert.

Principle of Least Surprise

Das Principle of Least Surprise (deutsch Prinzip der geringsten Überraschung) ist eigentlich ein Prinzip in der Software-Ergonomie, der Mensch-Computer-Interaktion und dem Interfacedesign. Es wird aber oft auch auf den Quellcode erweitert und betrifft im objektorientierten Design die Benennung von Variablen, Funktionen, Methoden, Parameter, Klassen und dergleichen. Sie sollen derart benannt werden, dass deren Funktion und mögliche Seiteneffekte alleine aus dem Namen klar erkenntlich sind.

Reuse-Release-Equivalence-Prinzip

Das Reuse-Release-Equivalence-Prinzip bezieht sich auf die Struktur von Packages im Sinne eines Moduls als kleinste Einheit eines Releases. Es gibt vor, dass sich Packages nur aus Klassen zusammensetzen dürfen, von denen entweder alle, oder gar keine zur Wiederverwendung gedacht sind.

Handelt es sich um ein wiederverwendbares Package, fordert das Prinzip zum einen, dass alle Änderungen nachvollzogen werden können und der Versionsverlauf zurückverfolgt werden kann, und zum anderen, dass nur Klassen enthalten sind, die auch für dieselbe Benutzergruppe gedacht sind (ein Benutzer, der eine Container-Class-Library wiederverwenden will, benötigt kein Finanz-Framework).

Common-Closure-Prinzip

Das Common Closure Prinzip fordert, dass alle Klassen in einem Modul gemäß dem Open-Closed-Prinzip geschlossen gegenüber derselben Art von Veränderungen sein sollten. Änderungen an den Anforderungen einer Software, welche Änderungen an einer Klasse eines Moduls benötigen, sollten auch die anderen Klassen des Moduls betreffen. Die Einhaltung dieses Prinzips ermöglicht es die Software derart in Module zu zerlegen, dass (zukünftige) Änderungen in nur wenigen Modulen umgesetzt werden können. Damit ist sichergestellt, dass Änderungen an der Software ohne große Seiteneffekte und somit relativ kostengünstig gemacht werden können.

Common-Reuse-Prinzip

Das Common-Reuse-Prinzip beschäftigt sich mit der Verwendung von Klassen. Es besagt, dass diejenigen Klassen, welche gemeinsam verwendet werden, auch gemeinsam zu einem Modul zusammengefasst werden sollten. Durch die Einhaltung dieses Prinzips wird eine Unterteilung der Software in fachlich bzw. technisch zusammengehörende Einheiten sichergestellt.

Acyclic-Dependencies-Prinzip

Das Acyclic-Dependencies-Prinzip fordert, dass die Abhängigkeiten zwischen Modulen zyklenfrei sein müssen. D. h. wenn Klassen in einem Modul von anderen Klassen in einem anderen Modul beispielsweise durch Vererbungs- oder Relationsbeziehungen abhängen, dann dürfen keine Klassen des anderen Moduls direkt oder indirekt von Klassen des ersteren Moduls abhängen.

Derartige Zyklen kann man immer aufbrechen. Dafür gibt es prinzipiell zwei Möglichkeiten:

• Anwendung des Dependency-Inversion-Prinzips: Wenn die Abhängigkeit von Package A auf Package B invertiert werden soll, so führe im Package von A Interfaces ein, welches die von B benötigten Methoden hält. Implementiere diese Interfaces in den entsprechenden Klassen von Package B. Somit wurde die Abhängigkeit zwischen Package A und B invertiert.
• Restrukturierung der Packages: Sammle alle Klassen eines Zyklus in einem eigenen Package zusammen und führe ein oder mehrere neue Packages ein, befüllt mit den Klassen von denen die Klassen außerhalb des Zyklus abhängen

Stable-Dependencies-Prinzip

Das Stable-Dependencies-Prinzip besagt, dass die Abhängigkeiten zwischen Modulen in Richtung der größeren Stabilität der Module gerichtet sein sollten. Ein Modul sollte also nur von Modulen abhängig sein, welche stabiler sind als es selbst.

Unter Stabilität versteht man hier das umgekehrte Verhältnis der ausgehenden Abhängigkeiten zur Summe aller Abhängigkeiten. Je weniger Abhängigkeiten ein Modul zu anderen hat und je mehr Abhängigkeiten andere Module zu diesem Modul haben, umso stabiler ist das Modul. Die Stabilität berechnet sich indirekt über die Instabilität folgendermaßen:

${\displaystyle I={\frac {Aa}{(Ae+Aa)}}}$
I … Instabilität eines Moduls
Ae … eingehende Abhängigkeiten (englisch afferent couplings)
Aa … ausgehende Abhängigkeiten (efferent couplings)

wobei sich ${\displaystyle Ae}$ und ${\displaystyle Aa}$ folgendermaßen berechnen:

• ${\displaystyle Ae}$ = Klassen außerhalb des Moduls, welche von Klassen innerhalb des Moduls abhängen
• ${\displaystyle Aa}$ = Klassen des Moduls, welche von Klassen außerhalb des Moduls abhängen

Die Instabilität liegt im Bereich von 0 bis 1, eine Instabilität von 0 weist auf ein maximal stabiles Modul hin, eine von 1 auf ein maximal instabiles Modul.

Stable-Abstractions-Principle

Das Stable-Abstractions-Prinzip fordert, dass die Abstraktheit eines Moduls direkt proportional zu seiner Stabilität sein muss.

Je abstrakter ein Modul ist – d. h. je mehr Interfaces, abstrakte Klassen und Methoden es hat –, desto stabiler sollte es sein. Generell errechnet sich die Abstraktheit eines Moduls folgendermaßen:

${\displaystyle A={\frac {Ka}{K}}}$
A … Abstraktheit eines Moduls
Ka … Anzahl abstrakter Klassen eines Moduls
K … Gesamtanzahl der Klassen eines Moduls

Für jedes Modul lässt sich die Distanz zur idealen Linie – englisch Main Sequence genannt – zwischen maximaler Stabilität und Abstraktheit und maximaler Instabilität und Konkretheit errechnen. Diese reicht von 0 bis ≈0,707:

${\displaystyle D={\frac {A+I-1}{\sqrt {2}}}}$
D … Distanz zur idealen Linie
A … Abstraktheit eines Moduls
I … Instabilität eines Moduls

Je größer die Distanz ist, desto schlechter ist das Stable-Abstractions-Prinzip erfüllt.