Property oder Member bei klasseninterner Benutzung



  • Hallo

    private int test;
    
    public int Test
    {
        get{return test;}
        set{test = value;}
    }
    

    eigentlich benutze ich aber immer AutoProperties.

    chrische



  • Benutzt du auch Properties, wenn es eine rein private Variable ist, die nach außen gar nicht sichtbar sein soll?



  • Hallo

    Nein.

    chrische



  • Wie benennst du in so einem Fall die Variable? Großer oder kleiner Anfangsbuchstabe?



  • Hallo

    Na ich halte mich da weitesgehend an die Konventionen, das heißt klein. Ich mache auch keinen Unterstrich.

    chrische



  • Zum Thema gab es zwei lesenswerte Beiträge auf Eric Lipperts (einer der C#-Compiler-Entwickler) Blog:

    Automatic vs Explicit Properties
    und
    Properties vs. Attributes

    Edit: Ok, der zweite passt nicht ganz ins Thema 🙂



  • Genau darauf wollte ich hinaus:
    Was machst du, wenn dir plötzlich auffällt, dass diese Variable doch irgendeine Prüfung oder Funktionalität braucht, die mit einem Property realisiert werden muss? Beispiel in einer Klasse "Spielfigur":

    private int lebensenergie;
    

    wird zu:

    private int lebensenergie;
    
    private int Lebensenergie
    {
        get { return lebensenergie; }
    
        set { lebensenergie = value < 0 ? 0 : value > 1000 ? 1000 : value; }
    } // Verdammt! Jetzt wurde die Variable schon an 100 Stellen benutzt,
      // ohne dass die Prüfung stattfindet.
    

    Deshalb schreibe ich auch simpelste Membervariablen (die keinem Property zugewiesen sind) groß: Wenn später Prüffunktionalität hinzukommt oder die Variable public werden soll, kann ich ohne Probleme ein Property hinzufügen: Die Variable wird dann in Kleinschreibung mit Unterstrich umbenannt und das Property heißt dann so, wie die Variable vorher hieß. Und schon zeigen sämtliche Verweise auf das Property, und nur das Property selbst verweist seinerseits direkt auf die Variable (es sei denn, es kommt der seltene Fall vor, dass die Variable an einer bestimmten Stelle in einem ungültigen Zustand sein soll. Dann wird natürlich auch dort direkt auf sie zugegriffen).
    Was würdest du in so einem Fall tun?

    Der Unterstrich ist übrigens eine programmiertechnische Sicherheitsmaßnahme, damit man auch selbst im oben genannten seltenen Fall sicher geht, dass die Membervariable nicht mit irgendeiner lokalen Variable verwechselt wird.



  • Hallo

    Für diesen Fall würde ich die Suchen & Ersetzen der IDE verwenden.

    chrische



  • Aber du siehst, dass das codetechnisch eigentlich nicht so sauber ist. Denn du musst manuell durch das Ding durchgehen oder irgendwelche IDE-Features beanspruchen, was potentielle Fehler produzieren kann.

    Außerdem unterminierst du damit deine eigene Aussage:
    [qupte]Also ich versuche immer das Property zu verwenden, schon alleine weil ich ja nicht weiß, ob ich get und set irgendwann noch erweitere.[/quote]
    In dem Fall könntest du ja auch sagen: "Ich benutze innerhalb der Klasse immer direkt die Variable. Wenn set und get des Propertys erweitert werden, benutze ich die Suchen/Ersetzen-Funktion, um die Variablenzugriffe in Propertyzugriffe umzuwandeln."



  • hajb schrieb:

    Automatic vs Explicit Properties

    Mir gefällt der letzte Benutzerkommentar in dem Artikel:

    I *NEVER* access the backing field outside of the propery. EVER.

    If I need different semantics, then I use different properties:

    Money Balance { get; set; }

    Money SecureBalance { get { if (...) throw; return Balance }


Anmelden zum Antworten