Prinzipien für den objektorientierten Entwurf - Architektur und Entwurfsmuster der Softwaretechnik - page 8

Kapsel aus Methoden
und Daten

Methodenköpfe sind die
Schnittstellen des Objekts
( Abstraktion ).

Daten und Methoden-
rümpfe sind verborgen
( Information Hiding ).
Die Daten können nur
über die eigenen
Methoden eines Objekts
manipuliert werden.

Daten

Methoden-
rumpf

Methodenkopf

Bild 1-1 Daten und Methoden - die Bestandteile von Objekten

Die Operationen bzw. Methoden auf den Daten eines Objekts werden als eine "innere
Fähigkeit" eines Objekts betrachtet. Wie die Operationen im Detail ablaufen, ist von
außen nicht sichtbar. Von außen ist nur sichtbar, wie eine Methode aufgerufen werden
kann.

1.3 Separation of Concerns und das Single Responsibility-
Prinzip

Das Single Responsibility-Prinzip gilt nur für Klassen, Separation of Concerns gilt prin-
zipiell. Vor dem Hintergrund der Objektorientierung sind diese beiden Prinzipien eng
miteinander verwandt.

Separation of Concerns ist ein altes Prinzip des Software Engi-
neering und besagt, dass jede Funktion, die einer getrennten Auf-
gabe entspricht, in einem eigenen Modul realisiert wird.

In der Veröffentlichung "On the role of scientific thought" postulierte Dijkstra [Dij82]: "It
is what I sometimes have called the separation of concerns , which, even if not
perfectly possible, is yet the only available technique for effective ordering of one's
thoughts, that I know of. This is what I mean by focussing one's attention upon
some aspect : it does not mean ignoring the other aspects, it is just doing justice to the
fact that from this aspect's point of view, the other is irrelevant". Für die Modularisie-
rung einer Verantwortlichkeit werden die anderen Verantwortlichkeiten also nicht be-
trachtet. Das sind jeweils eigene Module.

Der Begriff Single Responsibility-Prinzip stammt von Robert C.
Martin [marsrp] und ist auch in [Mar03] ausführlich beschrieben:

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

Übersetzt bedeutet das, dass es niemals mehr als einen Grund geben sollte, eine
Klasse zu ändern.