Lernen über Auto-Implementiert Eigenschaften

Question

Ich habe die einfache Klasse mit automatisch implementierte properies:

Public Class foo
{
    public foo() { }  

    public string BarName {get; set;}
}

ich natürlich die Variable BarName während meiner Klasse verwenden und jetzt Logik hinzufügen müssen, wenn der Wert der Eigenschaft gesetzt ist (es müssen alle Großbuchstaben eingegeben werden, gehen Abbildung). Bedeutet dies, dass ich muß jetzt eine private Variable für BarName schaffen, zum Beispiel _BarName, und ändern Sie die aktuelle BarName Variable während meiner Klasse verwendet, um _BarName?

Public Class foo
{
    public foo() {}  

    private string _BarName = "";
    public string BarName 
    { 
        get {return _BarName;}
        set {_BarName = Value.ToString().ToUpper();}
    }
}

Ich versuche sicher, dass ich die Auswirkungen der Verwendung von Auto-implementiertes verständlich zu machen Eigenschaften, und was es wird die Straße nach sich zieht ab, wenn / wenn ich etwas ändern müssen. Ich gehe davon aus, dass das Refactoring, wie oben gezeigt, ist kein Änderung zu brechen, da die Eigenschaft im Grunde die gleiche aufhält; es dauerte nur eine wenig Arbeit in der Klasse, es so zu halten und die benötigte Logik hinzufügen.

Ein weiteres Beispiel, das sinnvoller sein kann, ist, dass ich eine Methode aufrufen müssen, wenn ein Setter oder Getter verwendet wird; mehr als den Wert ändern.

Dies scheint einen fairen Handel von den Linien und Zeilen Code-Setup-Eigenschaften.

Answer 1

  

Bedeutet dies, dass ich jetzt brauche   Erstellen Sie eine private Variable für BarName

Ja

  

und die aktuellen BarName ändern   Variable während meiner Klasse verwendet

Sie nicht den Rest des Codes in Ihrer Klasse ändern, um die neue private Variable zu verwenden, die Sie erstellen. BarName , als Eigenschaft, sollte die private Variable (unter anderem), zum Zweck der Vermeidung der Kehr Änderungen, die Sie in Erwägung ziehen, um den Rest des Codes.

verstecken

  

Ich gehe davon aus, dass das Refactoring, wie   Oben genannten, ist kein Bruch Wechsel   im Grunde, weil die Eigenschaft   bleibt beim Alten; es dauerte nur ein   wenig Arbeit, es so zu halten und   fügen Sie die benötigte Logik.

Richtig.

Answer 2

Sie brauchen nichts zu ändern. Auto-implementiertes Eigenschaften sind nur syntaktischer Zucker. Der Compiler wird die private Variable zu erzeugen und get / set-Logik für Sie, hinter den Kulissen. Wenn Sie Ihren eigenen Getter / Setter-Logik hinzufügen, wird der Compiler den Code anstelle des automatisch generierten Code verwenden, aber so weit wie die Benutzer dieser Eigenschaft betrifft, hat sich nichts geändert; jeder Code Ihr Eigentum Referenzierung wird weiterhin funktionieren.

Answer 3

Wenn die automatische Eigenschaften mit Hilfe bekommt man nicht den direkten Zugriff auf die zugrunde liegenden „backing“ Variable und Sie keinen Zugriff auf die eigentliche Logik erhalten, die in der Eigenschaft Getter und Setter umgesetzt wird. Sie haben nur Zugriff auf die Eigenschaft (daher BarName im gesamten Code verwendet wird).

Wenn Sie nun spezifische Logik in der Setter implementieren müssen, können Sie nicht mehr automatisch Eigenschaften verwenden und müssen die Eigenschaft in der „altmodischen“ Art und Weise umzusetzen. In diesem Fall müßten Sie Ihre eigene private Trägergröße (die bevorzugte Methode implementieren, zumindest für mich, ist die private Unterstützung Variable die gleichen Namen wie die Eigenschaft zu nennen, aber mit einer anfänglichen Klein (in diesem Fall der Träger Variable mit dem Namen barName würde). Sie würden dann die entsprechende Logik in dem Getter / Setter implementieren.

In Ihrem Beispiel sind Sie richtig, dass es keine unterbrechende Änderung ist. Diese Art von Refactoring (von automatischen Eigenschaften bewegen zu „normalen“ Eigenschaften sollte nie eine Bruch Änderung sein, da Sie nicht die öffentliche Schnittstelle zu ändern sind (der Name oder die Zugänglichkeit des öffentlichen Eigentums).

Answer 4

Verwenden Sie keine automatische Eigenschaften, wenn Sie wissen, dass Sie das Objekt validieren werden. Diese Objekte können Domain-Objekte usw. sein wie wenn Sie eine Customer-Klasse dann private Variablen verwenden, da Sie benötigen den Namen, Geburtsdatum usw. zu validieren Aber wenn Sie eine Rss-Klasse verwenden, dann wird es in Ordnung sein, nur die automatischen Eigenschaften verwenden da es keine Validierung durchführen zu sein und die Klasse verwendet wird, nur einige Daten zu halten.

Answer 5

Sie sind richtig über das Refactoring und es sollte wirklich nichts kaputt machen.

Unabhängig davon, ob Sie tatsächlich benötigen, innerhalb der Klasse zu dem Eigenschaftsnamen durch die Referenzen gehen und diejenigen auf den privaten Bereich würde verweisen ändern davon ab, ob der interne Code benötigt, um die zugrunde liegende Darstellung der Daten zuzugreifen, anstatt, wie es wurde für die Verbraucher der Klasse vorgestellt. In den meisten Fällen kann man auch alleine genug verlassen.

Ihr einfaches Beispiel wäre es klug, gut verlassen genug allein und sicherzustellen, dass kein Code intern in der Klasse könnte die Konvertierung / Formatierung unterlaufen in der Setter durchgeführt wird.

Wenn auf der anderen Seite der Getter etwas Magie taten die interne Darstellung des Feldes in die Art und Weise der Verbraucher zu ändern, notwendig, um die Daten zu sehen dann vielleicht (in einigen Fällen), um den internen Code innerhalb der Klasse auf das Feld zuzugreifen müßten .

Sie müssen bei jedem Auftreten des Zugriffs auf die Auto-Eigenschaft in der Klasse suchen und entscheiden, ob sie das Feld oder mit der Eigenschaft berühren.

Answer 6

Automatische Eigenschaften sind nur syntaktischer Zucker, der Compiler in der Tat für die privaten Member schafft, aber da es bei der Kompilierung generiert wird, können Sie nicht darauf zugreifen.

Und später, wenn Sie Getter und Setter für die Eigenschaft implementieren mögen, nur dann erstellen Sie einen expliziten privaten Member für sie und die Logik hinzuzufügen.