🚀 go-pugleaf

Hi,
Arent Groebner (arent@pegasus.RoBIN.de) wrote:
: > Ralf Allar wrote:
: > >1) Deklariere alle Variablen als *protected*, damit sie abgeleiteten
: > >Klassen zur Verfügung stehen.
: >
: > Oh, Boy!
: >
: > Da hast Du aber was mit der OOP nicht verstanden!

: Ein bißchen weniger Überheblichkeit würde Dir nicht schaden...

Nun, er hat nicht ganz unrecht: Die Regel "alle Variablen als
protected" zu deklarieren ist GANZ SCHLECHT! Auch wenn es eine
Verwandschaftsbeziehung zwischen den Klassen gibt, sollte man sie nur
so wenig wie moeglich koppeln. Zugriff auf einen Member ist IMMER, egal
ob von einer abgeleiteten Klasse oder von ausserhalb, eine starke
Kopplung.

: > So umgehst Du ganz locker die Kapselung von Daten. Man brauch ja bei Deinen
: > Klassen nur zu erben, um Attribute manipulieren zu können! Böse, böse...

: Wenn man sich von einer Klasse ableitet, dann doch hoffentlich wegen einer  
: wohlbegründeten Verwandschaftsbeziehung. Dann ist aber auch der Zugriff  
: auf protected-Variablen wohlbegründet.

Nein. Zugriff auf Variablen innerhalb einer Klasse, ist fast nie
wohlbegruendet.  Software aendert sich. Immer. Das heisst auch, dass
sich eine Klasse aendern kann und dass man sie anders repraesentiert.
Damit aendern sich typischerweise die Member-Variablen. Wenn man sie
protected hatte, so kann man sie, de facto, NICHT aendern: Irgendeine
abgeleitete Klasse koennte darauf zugreifen. Die Design-Entscheidung
eine Variable in den protected (oder gar public) bereich zu stellen
sollte also sehr gut ueberdacht sein! Zugriffsfunktionen sind fast
immer eine bessere Alternative.

: > Also... NIEMALS Variablen protected machen, außer in Ausnahmefällen ...

: Das "NIEMALS" kannst Du getrost streichen. Mit dieser Art von Regeln  
: versucht man bloß Erstsemester zu disziplinieren.

Auch mit dem "niemals" hat er recht (insbesondere, da explizit auf
Ausnahmefaelle hingewiesen wird): Es ist normalerweise eine
Design-Entscheidung die man bitter bereut.  Die Klasse und ihre
Repraesentation WIRD sich aendern. Welche Member-Variablen davon
betroffen sein werden laesste normalerweise nicht vorher absehen.

: > Für den Zugriff sollten Memberfunktionen zur Verfügung gestellt werden,  
: > die dann protected bzw. public sind.

: Das ist bei Klassen richtig, die in keiner Vererbungsbeziehung stehen. Ein  
: Zugriff über Memberfunktionen ist bei abgeleiteten Klassen wohl doch etwas  
: übertrieben.

Nein. Es ist nicht uebertrieben. In einem Projekt, mit mehreren hundert
Files und aehnlich vielen Klassen ist es eine Katastrophe, wenn man
eine Aenderung in vielen Files und vielen Klassen machen muss. Wenn man
eine Variable aendert, egal ob ihren Typ oder ihren Namen oder was
sonst noch, auf die von beliebig vielen Stellen zugegriffen wird, dann
hat man ein Problem. Objekt-Oriented Design ist unter anderem dazu
gedacht, um genau solche Probleme zu vermeiden: Eine Klasse hat eine
abgekapselte Darstellung, auf die durch wohldefinierte Methoden
zugegriffen wird. Waehrend man Methoden so aendern kann, dass sie ihr
altes Verhalten beibehalten, kann man das mit Variablen normalerweise
nicht machen. Man sollte immer bedenken, dass beliebig viele Klassen
auf einen protected Member zugreifen koennen: Es kann beliebig viele
abgeleitete Klassen geben (ausser man verhindert, dass von der Klasse
abgelitten werden kann oder beschraenkt die Menge der Klassen, die
davon ableiten koennen).

... und noch was zum Thema "uebertrieben": Ich abstrahiere teilweise
innerhalb von Klassen von Variablen! Wenn mir mehrere Darstellung einer
Abstraktion sinnvoll erscheinen, dann implementiere ich oft sogar die
Member der Klasse selbst mittels Zugriffsfunktionen. Uebertrieben?
Nein: Es hat mich oft genug davor bewahrt, viele verstreute Aenderungen
machen zu muessen anstatt einige wenige, nicht verstreute Aenderungen
zu machen. Vielleicht waere sogar ein Konzept wie "very private"
angebracht (allerdings laesst sich das leicht durch Basisklassen
modellieren, was ich auch oft mache).
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic