Dieses Prinzip soll uns daran erinnern, dass eine Klasse stets nur eine Schlüsselabstraktion einfangen sollte. Anders formuliert: Jede Klasse sollte genau für eine Sache verantwortlich sein.
Zerfällt eine Schlüsselabstraktion (Verantwortlichkeit) in mehrere Klassen, so ist es wahrscheinlich, dass der Designer jede Funktion als eigene Klasse modelliert. Wenn umgekehrt mehrere Schlüsselabstraktionen in einer Klasse zusammengefasst werden, dann liegt die Vermutung nahe, dass der Entwickler ein zentralistisches System entwirft (Stichwort: Gottklassen). In beiden Fällen wirkt sich dies nachteilig auf die Änderungsfreundlichkeit aus:
- Wird eine Verantwortlichkeit auf mehrere Klassen verteilt, dann sind alle diese Klassen von Anforderungsänderungen betroffen, da sie einer engen Koppelung unterliegen. Systeme, die aus solchen Klassen bestehen, leiden in der Regel unter den gefürchteten Änderungskaskaden, bei denen bereits eine kleine Anpassung eine Reihe von weiteren Modifikationen an einer Vielzahl von Klassen nötig macht.
- Deckt eine Klasse dagegen mehr als eine Verantwortlichkeit ab, so sind diese Verantwortlichkeiten unnötig eng aneinander gekoppelt, so dass Änderungen bezogen auf eine Verantwortlichkeit dazu führen, dass die übrigen Verantwortlichkeiten der betroffenen Klasse u.U. nur noch eingeschränkt oder gar nicht mehr funktionieren werden.
Dieses Prinzip ist eines der einfachsten in der Objektorientierung überhaupt - und gleichzeitig eines der schwierigsten, richtig hinzubekommen.
Verantwortungsgetriebener Entwurf z.B. mit CRC-Karten ist ein wichtiges Hilfsmittel auf der Suche nach geeigneten Klassenentwürfen. Gefährlich ist dagegen die Verwendung von Use Cases, da diese aufgrund ihrer Skriptorientierung sowohl das Entwerfen von Gottklassen als auch die Fragmentierung der Verantwortlichkeiten begünstigen.
Experience is the hardest kind of teacher.