Eigenschaften und automatische Implementierungen

Question

Ich verwende .NET 4.5 in einem VSTO-Addin für Outlook 2013. Ich habe Probleme, Eigenschaften und Zugriffsmethoden vollständig zu erfassen. Automatisch implementierte Accessoren, die ich annehme, wenn du gerade schreibst, bekommst; einstellen; anstatt {// code} usw. zu bekommen, bereitet mir auch Schwierigkeiten. Ich habe ein Wörterbuch, das ich intern in meiner Klasse verwende. Hier ist mein Code:

private Dictionary<string, string> clientDict { get; set; } 
private Dictionary<string, string> clientHistoryDict { get; set; } 

dann später:

clientDict = new Dictionary<string, string>(); 
clientHistoryDict = new Dictionary<string, string>(); 

ich die gleichen Namen verwenden wie die Eigenschaften im Code später, innerhalb der gleichen Klasse.

Ich schreibe eigentlich nie:

private Dictionary<string, string> _clientDict; // etc. 

die Variablen erstellen ich direkt die Eigenschaft nur wurde mit.

Ich habe versucht, meinen Code zu ändern, um dies zu tun, und ich hatte einige Probleme und erkannte, dass mein Verständnis von Eigenschaften ein wenig durcheinander ist.

Hier sind ein paar Fragen, die ich geklärt haben muss, dass ich nicht scheinen kann, die richtige Antwort zu finden.

Erstens, gibt es einen Grund, ein Privateigentum zu benutzen? Auf meine Wörterbücher wird niemals außerhalb der Klasse oder in abgeleiteten Klassen zugegriffen. Gibt es also einen Grund, Eigenschaften zu verwenden? Ich verwende keine spezielle Validierung oder irgendetwas im Setter oder so etwas.

Zweitens, als ich versuchte, meinen Code zu ändern, um Variablen zu verwenden und dann über die Eigenschaften wie Ihr typisches Beispiel auf Eigenschaften zuzugreifen, stieß ich auf Probleme. Ich fand ein Beispiel, wo der Getter auf return _clientDict gesetzt wurde, aber der Setzer war nur Es gab mir den Fehler: dass ich einen Körper geben muss, weil es nicht abstrakt oder teilweise ist. Warum würde es den Setzer für mich in diesem Fall nicht automatisch implementieren?

Zuletzt, wenn ich neu auf die Eigenschaften in der gleichen Klasse, in der es deklariert ist, aufrufen, was ist der Unterschied zwischen dies mit einer Eigenschaft und eine normale Variable des gleichen Typs tun? Unterscheiden sich Eigenschaften in diesem Fall überhaupt von Variablen? Ist es eine schlechte Praxis, Eigenschaften auf diese Weise zu verwenden, wenn sie mit privaten Variablen ausgeführt werden sollen?

Diese können einige fehlgeleitete Fragen sein, aber ich kann keinen anderen Ort finden, der die Informationen hat, um mir zu helfen, diese Unterscheidungen zu verstehen. Ich habe mit Grundstücken herumgespielt, um das alles herauszufinden, aber ich könnte mir so Hilfe gebrauchen.

Answer 1

First, is there any reason to use a private property?

Normalerweise keine. Eigenschaften sind ideal für Kapselung. Ein Vorteil (es gibt manymore) der Verwendung einer Eigenschaft ist, dass es Validierungen vor der Zuweisung durchführen kann. Wenn Sie etwas haben private, brauchen Sie in der Regel nicht zum Schutz der Dinge von selbst. Eigenschaften haben auch den Vorteil, unterschiedliche Accessoren zu setzen (private, protected, usw.), wo Felder dies nicht tun.

Why would it not auto-implement the setter for me in this instance?

Wir müssen verstehen, dass automatisch implementierte Eigenschaften keine schwarze Magie sind. Der Compiler erzeugt ein privates Backing-Feld für uns, anstatt eines selbst zu erstellen.Aus seiner Sicht sieht er, dass Sie einen Getter haben, der ein privates Feld zurückgibt, aber der Setter ist automatisch, was normalerweise eine Art von logischem Fehler in Ihrem Code anzeigt. Warum würden Sie einen Wert zurückgeben, aber einen ganz anderen Wert einstellen? Wenn Sie eine Eigenschaft mit einem Backing-Feld erstellen, müssen Sie sowohl den Getter als auch die Setter, those are the rules, angeben.

when I call new on the properties in the same class that it is declared in, what is the difference between doing that with a property and a normal variable of the same type?

Semantisch Nichts. new gehört zu dem Typ, der erstellt wird, und gibt einen Konstruktoraufruf aus. Der Unterschied besteht darin, dass das neu erstellte Objekt zugewiesen wird. Ein Feld bewirkt, dass der Compiler einen stfld Opcode ausgibt. Für eine Eigenschaft wird eine call ausgegeben, um den Property Setter aufzurufen. Wenn Sie Zugriff auf eine Eigenschaft haben, ruft der Compiler get_YourPropertyName vs ldfld auf dem Feld auf.

Is it bad practice to use properties this way when it should be accomplished with private variables?

Ich würde es schlechte Praxis nicht nennen, aber ich würde es ein bisschen komisch finde eine private Eigenschaft zu haben.

Weitere Erkenntnisse über Felder und Eigenschaften finden What is the difference between a Field and a Property in C#?

Answer 2

Is there any reason to use a private property?

Nein - das ist der springende Punkt bei der automatischen Umsetzung. Es erspart Ihnen, all diesen zusätzlichen Code zu schreiben, wenn Sie nur das abrufen oder festlegen wollen, was sich in der privaten Member-Variable befindet. .Net verarbeitet die Erstellung der privaten Spiegelmitgliedschaftsvariablen hinter den Kulissen.

When I tried to change my code to use variables and then access them via the properties like your typical property example would, I ran into problems. I found an example where the getter was set to return _clientDict, but the setter was just set; It gave me the error: that I must give set a body because it's not abstract or partial. Why would it not auto-implement the setter for me in this instance?

Mein Verständnis ist, dass es alles oder nichts mit Auto-Implementierung ist. (Offen zur Korrektur dort aber). Das heißt, ich habe gesehen, Code kompilieren mit dem Set-Block einfach als set { } definiert. Edit: Nur um den set { } Block zu klären wird nicht wirklich den Wert, es schluckt im Wesentlichen den Aufruf und tut nichts - es wird jedoch kompilieren.

When I call new on the properties in the same class that it is declared in, what is the difference between doing that with a property and a normal variable of the same type? Do properties differ at all from variables in that case? Is it bad practice to use properties this way when it should be accomplished with private variables?

Es gibt keinen wirklichen Unterschied, soweit ich weiß. Genau das Gleiche passiert gerade, es ist nur so, dass .Net die Klempnerei für Sie erledigt.