Attribute, die gelesen und geschrieben werden, gehören nach public

So etwa wie in C. Nur weil C++ das Schlüsselwort private bereitstellt, heisst das nicht, dass man
es sich beim Schreiben oder Lesen von Attributen erschweren sollte!

Also ich ein paar Pro- und Contra-Argumente, was private Attribute anbelangt:

Contra:
- Für jedes Element müsste man 2 zusätzliche get- und set-Methoden bereitstellen. Bei vielen
Attributen wird das etwas anstrengend. Bei bereits 10 int-Elementen sind mir 20 get-, set-Methoden
zu viel. (Jetzt jedenfalls, später sind 20 vielleicht noch OK)
- get- und set-Methoden machen nur bei integralen Typen Sinn (Wert geben, Wert setzen). Bei
Containment versagt diese Methode. Oder sollte man alle Methoden einer std::list wrappen, nur
weil sie Element der Klasse ist? Wenn std::list Objekte jedoch in public steht, schreibt man
einfach klasse.liste.push_back(..)
- wenn mir mehr einfallen, sag ich Beischeid

Datenelemente, die jedoch nur oder gar nicht gelesen werden, können ruhig private sein.

Die Argumente, die dagegen sprechen, sind natürlich auch ganz wichtig, überzeugen mir jedoch nicht:
- Man geht von vornherein davon aus, dass alles in public eine Funktion ist. Und man ist daran gewöhnt.
- Bei get- und set-Methoden kann man zusätzliche Anweisungen (Berechnungen etc) ausführen.
Aber man könnte ja auch anstatt get oder set andere Funktionen mit dem passenden Namen erstellen,
beispielsweise get_calculated_thing()....
- und bestimmt viele mehr

Ich würde auch lieber jedes Attribut durch private schützen lassen, aber das Problem, dass set-Methoden
bei Containment keinen Sinn machen oder versagen (und ich keine Methoden wrappen will, weil scheisse und
häßlich) konnte ich bis jetzt nicht lösen. Alles andere würde der "packe Datenelemente immer nach private"-Devise
widersprechen. Funktionen, die Referenzen auf private Datenelemente liefern, finde ich unsinnig - bleibt aber
wenigstens dem "alles ist eine Funktion"-Argument treu.

Fazit: Attribute, die gelesen und geschrieben werden, gehören nach public

John Doe

Nominierung zum Troll der Woche.

otze

dann nehm ichs mal auseinander:

- Für jedes Element müsste man 2 zusätzliche get- und set-Methoden bereitstellen. Bei vielen
Attributen wird das etwas anstrengend. Bei bereits 10 int-Elementen sind mir 20 get-, set-Methoden

a) welche Klasse hat soviele lesbare elemente,ohne dass ein designproblem vorliegt? oftmals kann man das problem mit basisklassen lösen, es ist wzar immernoch dieselbe menge, aber nichtmehr soviel auf einem haufen. desweiteren bieten manche ides die funktion zum automatischen erstellen von setern/getern.

- get- und set-Methoden machen nur bei integralen Typen Sinn (Wert geben, Wert setzen).

was spricht dagegen, das objekt als referenz zu übergeben?
class.getList().push_back("ja, das geht auch");

was am meisten dafür spricht, ist, dass man mit getern pseudovariablen zurückgeben kann,die das ergebnis einer berechnung darstellen:

//ohne jetzt die formeln zu kennen
int Object::getEnergy(){
    return masse*geschwindigkeit*geschwindigkeit;
}
int Object::setEnergy(int Energy){
    geschwindigkeit=squart(Energy/masse);
}

desweiteren bilden get funktionen auch einen schutz für die integrität der Klasse, da verhindert wird, dass die Klassenvariablen für irgendwelche platzhalteraufgaben zweckentfremdet werden.

DrGreenthumb

Henrie schrieb:

Contra:
- Für jedes Element müsste man 2 zusätzliche get- und set-Methoden bereitstellen. Bei vielen
Attributen wird das etwas anstrengend. Bei bereits 10 int-Elementen sind mir 20 get-, set-Methoden
zu viel. (Jetzt jedenfalls, später sind 20 vielleicht noch OK)

10 int-Elemente, die alle von aussen gesetzt und gelesen werden sollen?
Gar nicht gut.

- get- und set-Methoden machen nur bei integralen Typen Sinn (Wert geben, Wert setzen). Bei
Containment versagt diese Methode. Oder sollte man alle Methoden einer std::list wrappen, nur
weil sie Element der Klasse ist? Wenn std::list Objekte jedoch in public steht, schreibt man
einfach klasse.liste.push_back(..)

nee, einfach klasse.add(). Im Idealfall weiß man beim Benutzen der Klasse überhaupt nicht, wie die Daten intern gespeichert werden.

Aber man könnte ja auch anstatt get oder set andere Funktionen mit dem passenden Namen erstellen,
beispielsweise get_calculated_thing()....

So ist es. Am besten man hat überhaupt keine get- oder set-Methoden, sondern denkt sich gleich die passenden Methoden aus, die die Daten bearbeiten.
Also besser auto.move(1) statt auto.setx(auto.getx()+1).

Fazit: public Datenelemente gibt es nicht.

protected auch nicht!! (Ok, bei mir gibt es zwei, aber die sind ein Designfehler)

phlox81

Optimizer schrieb:

protected auch nicht!! (Ok, bei mir gibt es zwei, aber die sind ein Designfehler)

Oh, doch. Protected macht imho immer mal wieder sinn.
Wenn man nach ist ein vererbt, dann hat jedes Auto reifen,
und wenn du dann von PKW erbst, hat jedes Auto sogar 4 Reifen...

Und imho machen GetMethoden immer mal wieder sinn, aber SetMethoden
allerhöchstens bei Datenklassen, wo irgendetwas konkret abgebildet wird.
Aber dann kann man es auch sinnvoller benennen.

Devil

Oh, doch. Protected macht imho immer mal wieder sinn.
Wenn man nach ist ein vererbt, dann hat jedes Auto reifen,
und wenn du dann von PKW erbst, hat jedes Auto sogar 4 Reifen...

Was ne geile Begründung. Wie stellst du dir das vor? PKW enthält ein Reifen-Datenelement, Auto erbt dieses protected und fügt noch drei hinzu? (Achtung: dieser Kommentar ist in böser Absicht leicht zynisch geschrieben, trotzdem wird um eine Erklärung für die zitierte Aussage gebeten)

phlox81

Optimizer schrieb:

Oh, doch. Protected macht imho immer mal wieder sinn.
Wenn man nach ist ein vererbt, dann hat jedes Auto reifen,
und wenn du dann von PKW erbst, hat jedes Auto sogar 4 Reifen...

Was ne geile Begründung. Wie stellst du dir das vor? PKW enthält ein Reifen-Datenelement, Auto erbt dieses protected und fügt noch drei hinzu? (Achtung: dieser Kommentar ist in böser Absicht leicht zynisch geschrieben, trotzdem wird um eine Erklärung für die zitierte Aussage gebeten)

PKW erbt von AUTO, da ein PKW ein AUTO ist, und hat dann 4 Reifen.
Dann erbt Golf,EKlasse oder 3erbmw von PKW.

AUTO könnte in dem fall auch Fahrzeug heissen, oder KFZ oder...

Devil

Das begründet in keinster Weise, warum jetzt die Reifen protected sein müssen.

phlox81

Optimizer schrieb:

Das begründet in keinster Weise, warum jetzt die Reifen protected sein müssen.

Äh, weil nicht jeder auf die Reifen zugreifen soll ?

Devil

Woah alter, ich rede davon, sie private zu machen und nicht public.

DrGreenthumb

protected-Variablen sind genau wie public. Die Basisklasse verliert die Kontrolle darüber.

Und was ist mit protected mett-hoden?

otze

die sind gut. Dass policysystem nach alexandrescou basiert drauf

//edit aber nur wenn mett-hoden keinen bindestrich haben