Konstruktor-Initialisierung

[stealth00]

wie wäre es mit einer protected const float SpeedFactor; die mit dem Konstruktor initialisiert wird!
Wäre vielleicht eine annehmbare Lösung oder?

[HumeSikkins]

Einige Leute (z.B. Herr Fowler, wenn ich mich nicht irre) plädieren sogar mit ziemlich guten Gründen dafür, selbst in der Klasse, der die Variablen gehören, ausschließlich per Methode darauf zuzugreifen.

@Stefan D.
Nein der Herr Fowler war es nicht (vgl. "Refactoring - Improving the design of existing code" Seite 170f:). Abgeneigt ist er allerdings auch nicht.

Ansonsten stimme ich StefanD zu. Instanz-Variablen sollten private sein. Nicht protected. Und zwar nicht protected aus *exakt* dem selben Grund warum sie nicht private sein sollten. Ein nicht private Instanzvariable liegt *außerhalb* der Kontrolle des Klassenbauers. Es kann potentiell unendlich viel Code existieren der von dieser Variablen *abhängig* ist. Wird die Variable geändert oder entfernt, so kann potentiell unendlich viel Code dabei kaputt gehen. Code der nicht im Verantwortungsbereich des Klassenbauers liegt. Damit kann letztlich kaum noch eine Änderung durchgeführt werden.

Man hat letztlich *exakt* die selhen Abhängigkeiten wie bei public Instanzvariablen.

Das gilt natürlich alles nicht für Leute die immer nur für sich allein in einem Ein-Mann-Unternehmen entwickeln bzw. die immer allen Code besitzen. Nur auf wen trifft sowas zu?

[ Dieser Beitrag wurde am 27.06.2003 um 00:50 Uhr von HumeSikkins editiert. ]

[Shade Of Mine]

Original erstellt von stealth00:
Aber wenn die Klasse nur von EINER Kontrollklasse verwendet wird, ist es doch relativ wurscht ob man direkt auf die Vars zugreift oder setter und getter einbaut.

na dann waere eine struct wohl besser - nur offene daten...
halt moment mal!
was wenn wir wollen dass diese Klasse ihr verhalten aendert? So soll die Variable brueckenoffiziere nie mehr als 12 sein duerfen (weil mehr als 12 nicht auf die bruecken passen) - was machst du dann?

Oder wenn du eine neue Variable hinzufuegst: LeuteAufBruecke - welche von brueckenoffiziere abhaengig ist (nur dass uU noch besucher dazu kommen koennen).

Dann musst du LeuteAufBruecke ja updaten wenn ein brueckenoffizier mal schnell nen kaffee trinken geht (nur leider geht das nicht, denn irgendwo im code steht dann ja:

raumschiff.brueckenoffiziere-=2;
anstatt
raumschiff.BrueckenoffizierLeave();
raumschiff.BrueckenoffizierLeave();
oder aehnliches.

obwohl deine klasse nur von einer anderen verwendbar ist, so ist sie doch eigenstaendig, oder?

Dein Beispiel mit den Raumschiffen:
was ist besser:
//increment speed by 2 steps
Raumschiff.speed+= (2*SPEED_KONSTANTE_FUER_DIESES_RAUMSCHIFF);
//denn du bist spaeter drauf gekommen dass raumschiffe eine verschiedene step weite haben...
oder
Raumschiff.faster(2);

faster koennte virtual sein und jedes raumschiff weiss wie gross so ein schritt ist.

dabei bleibt speed private in BaseShip, denn es gibt in BaseShip ja ne protected methode: incrementSpeed()
und faster sieht so aus:

virtual void faster(int step)
{
incrementSpeed(step*SPEED_KONSTANTE);
}

und incrementSpeed sieht dann so aus:

void incrementSpeed(double inc)
{
if(speed+inc > MAXIMAL_WERT)
throw "wir sind an der lichtmauer zerschellt";

speed+=inc;
}

da gibts viele moeglichkeiten, sicher auch bessere als ich hier gezeigt habe - aber worauf ich hinaus will: ich hab noch nie klasse geschrieben die public member hatte, oder wo alle member einen setter und einen getter hatten...

ich sehe als beim besten willen keinen grund warum es bei dir anders sein sollte. oder willst du diese nachteile wirklich in kauf nehmen??

[volkard]

ganz egal, ob man allein arbeiteitet oder im team. protected tut weh.
wenn man volkards fehlersuchregeln durchstöbert, steht da auch:
"du bist nicht weniger tapsig, als deine arbeitskollegen. wirksame schutzmechanismen gegen die fremden eumel haste auch gegen dich selbst anzuwenden."

[ Dieser Beitrag wurde am 27.06.2003 um 07:25 Uhr von volkard editiert. ]

[StefanD]

du bist nicht weniger tapsig, als deine arbeitskollegen. wirksame schutzmechanismen gegen die fremden eumel haste auch gegen dich selbst anzuwenden.

Amen!!!!

Stefan.