Klassenparameter direkt beschreiben?

Ich habe eine Klasse mit private Membern und den Get/Set Properties.
Wenn ich in der selben Klasse mit den Daten arbeite, schreibe ich dann direkt in die privaten Member oder schalte ich auch hier die Properties dazwischen? Im Allgemeinen sollten die privaten Member schon korrekt sein und bedürfen keiner erneuten Überprüfung durch die Getter und Setter.

volkard

Im Allgemeinen direkt.

Jockelx

Die einen sagen so, die anderen so. Ich sehe das ähnlich wie Volkard.

Fragender Tun schrieb:

Im Allgemeinen sollten die privaten Member schon korrekt sein und bedürfen keiner erneuten Überprüfung durch die Getter und Setter.

Mag sein, aber Vorsicht bei Vererbung. Das Verhalten wäre anders, wenn man in Base den getter oder den Member direkt aufruft, falls der abgeleitete getter zB noch +10 rechnet oder sowas.

volkard schrieb:

Im Allgemeinen direkt.

Ich sehe das auch wie volkard. Der gute Herr Breymann sagte einmal, ihm ist das gleich. Also insgesamt Geschmackssache.

volkard schrieb:

Im Allgemeinen direkt.

OK, gucken wir mal:

class Test
{
private:

    int m_Percent;
    // ... (andere Member)

public:

    int GetPercent
    {
        return m_Percent;
    }

    void SetPercent(int percent)
    {
        if (percent < 0 || percent > 100)
            throw exception("Fehlerhafter Wert.");
        else
            m_Percent = percent;
    }

    void SetMultipleValues(int wasAnderes, int percent)
    {
        // Setze wasAnderes:
        // ...

        // Setze percent:

        // Alternative 1:
        SetPercent(percent);

        // Alternative 2:
        m_Percent = percent;
    }
};

Wenn du percent durch die Funktion SetMultipleValues setzt, willst du ja sicher auch, dass die Prüfung und ggf. eine Exception geworfen wird, wenn der Wert falsch ist, oder?

Also benutzt man auch intern immer die Setter und Getter. Denn du weißt nie, wann aus dem einfachen Setter m_Value = value mal irgendeine komplizierte Prüffunktion wird. Willst du dann erst manuell durch die gesamte Klasse gucken, wo du die Membervariable direkt verändert hast, und dann durch den Setter ersetzen?

Bei C# ist das ja ähnlich: Wenn du ein Auto-Property hast, das dann doch zu einem herkömmlichen Property mit Membervariable wird, müsstest du nach deiner Logik überall intern das Property durch den Member ersetzen. Weil, intern werden ja bei dir nicht die Propertys, sondern die Member verwendet.
Und andersrum müsstest du bei jedem normalen Property, das zum Auto-Property wird, überall die Aufrufe des (nun nicht mehr vorhandenen) Members durch das Property ersetzen.
Und falls das Auto-Property doch wieder ein Backing-Field bekommt, müssen diese Aufrufe wieder das Backing-Field werden, damit es nicht mal so und mal so gehandhabt wird.

Deshalb: Immer die Setter/Getter/Propertys benutzen. Dann erspart man sich den ganzen Mist und hat es immer konsistent.

Jockelx

Setter4Life schrieb:

volkard schrieb:

Im Allgemeinen direkt.

OK, gucken wir mal:

Wow! Du hast ein Gegenbeispiel gefunden!
Hat nur mit unseren 'im Allgemeinen', bzw dem 'privaten Member schon korrekt sein und bedürfen keiner erneuten Überprüfung ' vom Fragesteller nix zu tun.

Setter4Life schrieb:

Denn du weißt nie, wann aus dem einfachen Setter m_Value = value mal irgendeine komplizierte Prüffunktion wird.

Schliesse nicht von dir (oder zugegeben dem Inhalt vieler Bücher) auf andere.
Ich kann das ziemlich sicher immer sagen, ob ein Wert vielleicht doch mal einen Setter brauchen könnte. Im Zweifel gibts halt nen Setter.
Ausserdem tun hier immer zu Viele, als ob sie Libs für 1000de Leute schreiben, wo eine Änderung im Interface nicht durchführbar ist.

Mechanics

Jockelx schrieb:

Ausserdem tun hier immer zu Viele, als ob sie Libs für 1000de Leute schreiben, wo eine Änderung im Interface nicht durchführbar ist.

Sein Argument hat denke ich nichts mit Änderungen im Interface zu tun.

Im übrigen setze ich Klassenmember auch lieber direkt. Es ist zu 99% klar, ob das problematisch ist oder werden könnte, und wenn das nicht problematisch ist, dann will ich sehen, was passiert, statt ständig in irgendwelche Funktionsaufrufe reinzuspringen um zu sehen, was die gleich wieder machen. Wenn deine Klasse so unübersichtlich ist, dass du intern nicht durchblickst, ob du irgendwelche zusätzlichen Prüfungen brauchst, dann ist wahrscheinlich was ganz anderes falsch.

hustbaer

Setter4Life schrieb:

Deshalb: Immer die Setter/Getter/Propertys benutzen. Dann erspart man sich den ganzen Mist und hat es immer konsistent.

Das ist BS. Was bei einer so absoluten Aussage auch nicht verwunderlich ist.

Es kann im Setter genau so gut Checks oder allgemein Code geben, der nicht immer laufen sollte. z.B. während man gerade temporär Invarianten zerstört hat (die man vor Beendigung der Methode natürlich wieder geradebiegt).
Wenn du immer die Setter verwendest, dann bekommst du in solchen Fällen ein Problem.

Es kann auch sein dass die Checks im Setter relativ aufwendig sind. Wenn man dann einen Wert setzt von dem man *weiss* dass er OK ist, ... wozu Rechenzeit verbraten für nichts (Korrektur: für "damit es immer konsistent ist")?

Jockelx

Mechanics schrieb:

Jockelx schrieb:

Ausserdem tun hier immer zu Viele, als ob sie Libs für 1000de Leute schreiben, wo eine Änderung im Interface nicht durchführbar ist.

Sein Argument hat denke ich nichts mit Änderungen im Interface zu tun.

Ich lese aus der Argumentation aber ein 'alle Member brauchen immer getter/setter' raus.
Hab einfach schonmal im voraus auch darauf geantwortet