?
Ergänzend: Das Problem aus meiner Sicht mit den ganzen gettern/settern ist, dass man dann dazu neigt, die eigentliche Funktionalität außerhalb der Klasse anzusiedeln; die dient dann nämlich nur noch als quasi-public Datenhaltungsobjekt (aka struct). Ich kenne sowas eher von Java, kann aber nicht beurteilen, inwiefern das da mehr Sinn macht.
Im Allgemeinen sagt man ja, jede Klasse hat genau eine Aufgabe. Und die ist es nicht, nur Daten zu halten. Sie sollte möglichst wenige Interna offenlegen und alle Veränderungen an sich selbst abstrakter kapseln als mit einem setXXX. Containerklassen wie std::vector o.Ä. seien hier eine Ausnahme.
Als Anfänger geht man oft bottom-up dran - man überlegt, was die Klasse für Attribute hat und natürlich muss man alle abfragen und setzen können (wegen "was ist, wenn man aber blubb machen will"). Oft eignet sich imho ein top-down Ansatz aber besser, man überlegt also, wie man die Klasse verwenden würde. Eventuell verwendet man die noch-nicht-existente-oder-designte Klasse in Pseudocode, um ein Gefühl an die Anforderungen zu entwickeln. Und meiner Erfahrung nach kommt dann sowas Unterschiedliches dabei raus:
Szenario: Uhr-Klasse, z.B. für ein Gadget wie hier.
Was ich bei Anfängern oft sehe:
class clock {
public:
clock();
void draw( ... );
int getHours() const;
void setHours( int Hours );
int getMinutes() const;
void setMinutes( int Minutes );
int getSeconds() const;
void setSeconds( int Seconds );
};
Eigentlich aber braucht man nur sowas:
class clock {
public:
clock( int Hours, int Minutes, int Seconds );
void tick(); // Erhöht Zeit um eine Sekunde
void draw( ... );
};
Oder vielleicht auch nur:
class autoclock {
public:
autoclock();
void draw( ... ); //Zeichnet einfach aktuelle Systemzeit
};
Das Schlechte an der allerersten Variante ist, dass das Fenster, das die Uhr beinhaltet, in seiner Funktion zum Zeichen der Uhr erst die Uhrzeit setzen muss. Klar, sind nur ein oder zwei Zeilen aber die Logik gehört da nicht hin (in diesem Anwendungsfall). Es ist zwar maximal flexibel, aber lagert die Verantwortung nur aus, weg ist sie ja nicht; nur sind Klassen eben dazu da, uns Arbeit abzunehmen.
Abschließend: Man neigt leider (ich ja auch) oft dazu, alles so generell und flexibel wie möglich entwerfen zu wollen. So, dass auch der letzte Hansel es für ein komplett anderes Projekt verwenden könnte und ich genau diese Klasse selbst in 10 Jahren auf einem anderen Rechnertyp mit anderem OS wiederverwenden kann. Das hat aber nun mal seinen Preis, besonders im Hinblick auf die Verständlichkeit. Oft reicht es, für den aktuellen Stand zu designen und dabei ein wenig mögliche zukünftige Änderungen und Anforderungen einzuplanen.
