Prinzipien Objektorientierten Designs

Prinzipien Objektorientierten Designs sind Prinzipien welche zu gutem objektorientierten Design führen sollen. Sie wurden neben anderen von Robert C. Martin, Bertrand Meyer und Barbara Liskov publiziert und propagiert. Viele Techniken der Objektorientierung wie Entwurfsmuster, Domain-Driven Design oder Dependency Injection basieren auf diesen Prinzipien objektorientierten Designs.

Für eine Gruppe dieser Prinzipien wurde von Robert C. Martin das Akronym “SOLID” geprägt. Diese Prinzipien gemeinsam angewandt führt lt. Robert C. Martin zu einer höheren Wartbarkeit und somit Lebensdauer von Software. Diese Prinzipien sind das “Single Responsibility Prinzip”, das “Open-Closed Prinzip”, das “Liskovsches Substitutionsprinzip”, das “Interface Segregation Prinzip” und das “Dependency Inversion Prinzip”.

Darüber hinaus gibt es noch eine Reihe weiterer mehr oder weniger bekannter Prinzipien objektorientierten Designs wie Design by Contract oder das Gesetz von Demeter. Eine Sonderstellung unter den Prinzipien objektorientierten Designs haben die sogenannten Packaging Prinzipien, da diese sich alle mit der Gruppierung von Klassen zu Packages beschäftigen.

SOLID Prinzipien

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:

„There should never be more than one reason for a class to change.“

„Es sollte nie mehr als einen Grund dafür geben, eine Klasse zu ändern.“

– Robert C. Martin: Agile Software Development: Principles, Patterns, and Practices^[1]

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 etc.) 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:

„Modules should be both open (for extension) and closed (for modification).“

„Module sollten sowohl offen (für Erweiterungen), als auch geschlossen (für Modifikationen) sein.“

– Bertrand Meyer: Object Oriented Software Construction^[2]

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.^[3] In einem nachfolgenden Artikel wurde es folgendermaßen formuliert:

„Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.“

„Sei q(x) eine Eigenschaft des Objektes x vom Typ T, dann sollte q(y) für alle Objekte y des Typs S gelten, wo S ein Subtyp von T ist.“

– Barbara H. Liskov, Jeannette M. Wing: Behavioral Subtyping Using Invariants and Constraints^[4]

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, das 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.^[5]

Interface Segregation Prinzip

Das Interface Segregation Prinzip dient dazu, zu große Interfaces aufzuteilen. Die Aufteilung soll gemäß der 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:

„Clients should not be forced to depend upon interfaces that they do not use.“

„Clients sollten nicht dazu gezwungen werden, von Interfaces abzuhängen, die sie nicht verwenden.“

– Robert C. Martin: The Interface Segregation Principle^[6]

Mit Hilfe des Interface Segregation Prinzip 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^[7] und später folgendermaßen formuliert:

„A. High-level modules should not depend on low level modules. Both should depend on abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.“

„A. Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen. Beide sollten von Abstraktionen abhängen.
B. Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.“

– Robert C. Martin: The Dependency Inversion Principle^[8]

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.

Weitere Prinzipien Objektorientierten Designs

Neben der von Robert C. Martin propagierten SOLID Gruppe von Prinzipien Objektorientierten Designs sind noch folgende Prinzipien als Prinzipien Objektorientierten Designs bekannt:

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:

„A supplier object to a method M is an object to which a message is set in M. The preferred supplier objects to method M are: The immediate parts of self or the argument objects of M or the objects which are either objects created directly in M or objects in global variables.
Every supplier object to a method must be a preferred supplier.“

„Ein Unterstützendes Objekt der Methode M ist ein Objekt, an welches aus M Nachrichten gesendet werden. Die Bevorzugten Unterstützenden Objekte der Methode M sind: Das Objekt der Methode M, die Argumente von M oder die Objekte die direkt in M erzeugt werden oder Objekte in globalen Variablen.
Jedes Unterstützende Objekt einer Methode muss ein Bevorzugtes Unterstützendes Objekt sein.“

– Karl J. Lieberherr, I. Holland: Assuring good style for object-oriented programs^[9]

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.^[10] 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 statt dessen ü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 Principle

Das Linguistic Modular Units Principle (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:

„Modules must correspond to syntactic units in the language used.“

„Module müssen den syntaktischen Einheiten der verwendeten Sprache entsprechen.“

– Bertrand Meyer: Object Oriented Software Construction^[11]

Self-Documentation principle

Das Self-Documentation Principle (englisch für Selbst-Dokumentierungs Prinzip) 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:

„The designer of a module should strive to make all information about the module part of the module itself.“

„Beim Entwurf eines Modules sollte man danach trachten, dass alle Informationen über das Modul, selbst Teil des Moduls sind.“

– Bertrand Meyer: Object Oriented Software Construction^[12]

Uniform Access Principle

Das Uniform Access Principle (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:

„All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.“

„Alle Services eines Moduls sollten mittels einer gleichartigen Notation angeboten werden; eine Notation, welche nicht preisgibt, ob sie über Datenzugriffe oder Berechnungen umgesetzt wurden.“

– Bertrand Meyer: Object Oriented Software Construction^[13]

Single Choice Principle

Das Single Choice Principle 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:

„Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.“

„Immer wenn eine Software unterschiedliche Alternativen unterstützt, sollte es nur genau ein Modul geben, welche die Liste der Alternativen kennt.“

– Bertrand Meyer: Object Oriented Software Construction^[14]

Persistence Closure Principle

Das Persistence Closure Principle 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.

„Whenever a storage mechanism stores an object, it must store with it the dependents of that object. Whenever a retrieval mechanism retrieves a previously stored object, it must also retrieve any dependent of that object that has not yet been retrieved.“

„Wenn ein Speichermechanismus ein Objekt speichert, muss es auch dessen Abhängigkeiten speichern. Wenn ein Lademechanismus ein vorher gespeichertes Objekt lädt, muss er auch dessen bisher noch nicht geladenen Abhängigkeiten laden.“

– Bertrand Meyer: Object Oriented Software Construction^[15]

Packaging Prinzipien

Die folgenden von Bertrand Meyer und Robert C. Martin definierten Prinzipien beschäftigen sich mit der Frage, wie man Klassen zu Modulen (Packages) zusammenführen sollte. Sie führen insbesondere zu einer hohen Kohäsion innerhalb der Module und geringen Kopplung zwischen den Modulen.

Reuse Release Equivalence Prinzip

Das Reuse Release Equivalence Prinzip besagt dass diejenigen Klassen, welche üblicherweise gemeinsam released werden, zu Modulen zusammengeführt werden sollten. Damit wird gewährleistet, dass die Anzahl der zu verteilenden Module möglichst gering gehalten wird, was wiederum die Aufwände der Softwareverteilung reduziert.

„The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package.“

„Die Granularität der Wiederverwendung ist die Granularität der Release. Nur Komponenten, welche durch ein Tracking System released werden, können effektiv wiederverwendet werden. Diese Granularität ist das Package.“

– Robert C. Martin: Granularity^[16]

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.

„The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package.“

„Klassen eines Packages sollten gemeinsam geschlossen gegenüber denselben Arten von Veränderung sein. Eine Änderung, die ein Package betrifft, sollte alle Klassen dieses Packages betreffen.“

– Robert C. Martin: Granularity^[17]

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.

„The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.“

„Die Klassen eines Packages sollten gemeinsam wiederverwendet werden. Wenn man eine Klasse eines Packages wiederverwendet, sollte man alle Klassen des Packages wiederverwenden.“

– Robert C. Martin: Granularity^[18]

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.

„The dependency structure between packages must be a directed acyclic graph (DAG). That is, there must be no cycles in the dependency structure.“

„Die Abhängigkeiten zwischen Packages müssen einem gerichteten azyklischen Graphen entsprechen. Das bedeutet, dass es keine Zyklen in der Abhängigkeitsstruktur geben darf.“

– Robert C. Martin: Granularity^[19]

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.

„The dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is.“

„Die Abhängigkeiten zwischen Packages sollten in der selben Richtung wie die Stabilität verlaufen. Ein Package sollte nur von Packages abhängen, welche stabiler als es selbst sind.“

– Robert C. Martin: Stability^[20]

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:

$I=\frac{Aa}{(Ae+Aa)}$

I .. Instabilität eines Moduls Ae .. eingehende Abhängigkeiten (engl. afferent couplings). Aa .. ausgehende Abhängigkeiten (engl. efferent couplings).

wobei sich Ae und Aa folgendermaßen berechnen:

• Ae = Klassen außerhalb des Moduls, welche von Klassen innerhalb des Moduls abhängen
• 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.

„Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. The abstraction of a package should be in proportion to its stability.“

„Packages die maximal stabil sind sollten maximal abstrakt sein. Instabile Packages sollten konkret sein. Die Abstraktheit eines Packages sollte proportional zu seiner Stabilität sein.“

– Robert C. Martin: Stability^[21]

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:

$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 - engl. Main Sequence genannt - zwischen maximaler Stabilität und Abstraktheit und maximaler Instabilität und Konkretheit errechnen. Diese reicht von 0 bis ~0,707:

$D=\frac{A+I-1}{\sqrt 2}$

D .. Distanz zur idealen Linie A .. Abstraktheit eines Moduls I .. Instabilität eines Moduls

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

Siehe auch

• Ockhams Rasiermesser - ein Sparsamkeitsprinzip aus der Wissenschaftstheorie
• Entwurfsmuster - lösen wiederkehrende Entwurfsprobleme basierend auf den Designprinzipien
• GRASP - Entwurfsmuster, mit denen die Zuständigkeit bestimmter Klassen objektorientierter Systeme festgelegt wird
• Domain-Driven Design - Vorgehensmodell zur Modellierung komplexer Softwaresysteme

Literatur

• Robert C. Martin: Agile Software Development. Principles, Patterns, and Practices. Pearson Education, Upper Saddle River, NJ 2002, ISBN 0-13-597444-5.
• Robert C. Martin: Design Principles and Design Patterns. www.objectmentor.com, 2000 (online (PDF; 162 KB)).
• Bertrand Meyer: Object-Oriented Software Construction. Prentice Hall, New York u. a. 1988, ISBN 0-13-629049-3.
• Richard Pawson, Robert Matthews: Naked Objects. John Wiley & Sons, Chichester u. a. 2002, ISBN 0-470-84420-5.

Weblinks

• http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign
• http://c2.com/cgi/wiki?OoDesignPrinciples

Einzelnachweise

1. ↑ Robert C. Martin: Agile Software Development: Principles, Patterns, and Practices. Prentice Hall, 25. Oktober 2002, ISBN 978-0135974445, S. 149-153 (http://www.objectmentor.com/resources/articles/srp.pdf).
2. ↑ Bertrand Meyer: Object Oriented Software Construction. Prentice Hall, 1988, ISBN 978-0136291558, S. 57-61.
3. ↑ Barbara H. Liskov, Jeannette M. Wing: Family Values: A Behavioral Notion of Subtyping. Pittsburgh 1993.
4. ↑ Barbara H. Liskov, Jeannette M. Wing; MIT Lab. for Computer Science, School of Computer Science, Carnegie Mellon University (Hrsg.): Behavioral Subtyping Using Invariants and Constraints. Prentice Hall, Pittsburgh Juli 1999 (http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-156.ps).
5. ↑ Lahres , Rayman: Praxisbuch Objektorientierung. Seiten 153–189, siehe Literatur
6. ↑ Robert C. Martin: The Interface Segregation Principle. Object Mentor, 1996 (http://www.objectmentor.com/resources/articles/isp.pdf).
7. ↑ Robert C. Martin: Object Oriented Design Quality Metrics. an analysis of dependencies. In: C++ Report. September/Oktober 1995 Auflage. 28. Oktober 1994 (http://www.objectmentor.com/resources/articles/oodmetrc.pdf, abgerufen am 26. Juli 2010).
8. ↑ Robert C. Martin: The Dependency Inversion Principle. bject Mentor, Mai 1996 (http://www.objectmentor.com/resources/articles/dip.pdf).
9. ↑ Karl J. Lieberherr, I. Holland: Assuring good style for object-oriented programs. In: IEEE Software. S. 38 - 48 (http://citeseer.ist.psu.edu/lieberherr89assuring.html, abgerufen am 27. Februar 2010).
10. ↑ Bertrand Meyer: Object Oriented Software Construction. Prentice Hall, 1988, ISBN 978-0136291558, S. 18.
11. ↑ Bertrand Meyer: Object Oriented Software Construction. Prentice Hall, 1988, ISBN 978-0136291558, S. 53-54.
12. ↑ Bertrand Meyer: Object Oriented Software Construction. Prentice Hall, 1988, ISBN 978-0136291558, S. 54-55.
13. ↑ Bertrand Meyer: Object Oriented Software Construction. Prentice Hall, 1988, ISBN 978-0136291558, S. 55-57.
14. ↑ Bertrand Meyer: Object Oriented Software Construction. Prentice Hall, 1988, ISBN 978-0136291558, S. 61-63.
15. ↑ Bertrand Meyer: Object Oriented Software Construction. Prentice Hall, 1988, ISBN 978-0136291558, S. 252-253.
16. ↑ Robert C. Martin: Granularity. In: IEEE Software. Dezember 1996, S. 4 (http://www.objectmentor.com/resources/articles/granularity.pdf, abgerufen am 24. April 2010).
17. ↑ Robert C. Martin: Granularity. In: IEEE Software. Dezember 1996, S. 6 (http://www.objectmentor.com/resources/articles/granularity.pdf, abgerufen am 24. April 2010).
18. ↑ Robert C. Martin: Granularity. In: IEEE Software. Dezember 1996, S. 5 (http://www.objectmentor.com/resources/articles/granularity.pdf, abgerufen am 24. April 2010).
19. ↑ Robert C. Martin: Granularity. In: IEEE Software. Dezember 1996, S. 6 (http://www.objectmentor.com/resources/articles/granularity.pdf, abgerufen am 24. April 2010).
20. ↑ Robert C. Martin: Granularity. In: IEEE Software. Dezember 1997, S. 8-11 (http://www.objectmentor.com/resources/articles/stability.pdf, abgerufen am 24. April 2010).
21. ↑ Robert C. Martin: Granularity. In: IEEE Software. Dezember 1997, S. 11-14 (http://www.objectmentor.com/resources/articles/stability.pdf, abgerufen am 24. April 2010).