Ich habe einige Diskussionen über dieses Thema gelesen, und da ist etwas, das ich einfach nicht verstehe.
Die häufigste Antwort scheint dies zu sein: Verwenden Sie eine ReadOnly-Eigenschaft, um zwischengespeicherte Daten zurückzugeben, verwenden Sie eine Funktion, um nicht zwischengespeicherte Daten zurückzugeben. Verwenden Sie keine WriteOnly-Eigenschaft, denn "es ergibt keinen Sinn".
Es gibt keinen Leistungsgrund dafür. In IL existiert MyProperty als get_MyProperty und set_MyProperty Methoden. Der einzige Grund ist offensichtlich, dass die obige Antwort angenommen werden sollte.
Ok, warum sollte man sich dann überhaupt mit ReadOnly Properties beschäftigen? Warum nicht einfach die Variable Public statt Private machen? Warum sollten Sie sich dann mit Eigenschaften beschäftigen? Zwischengespeicherte Daten - & gt; Öffentliche Variable, nicht zwischengespeicherte Daten - & gt; Funktion, Daten schreiben - & gt; Sub
Vergessen wir all das oben Gesagte und verwenden Sie Eigenschaften als praktische Funktion? Ein 'Element' zum Abrufen und Festlegen von Daten. Verwenden Sie gesunden Menschenverstand, um zu wissen, ob ein Get zwischengespeicherte Daten nicht zurückgibt (was möglicherweise zu einer Verzögerung führt).
-Edit- Ich sehe Leute mehr oder weniger zustimmen, dass Eigenschaften die beste Option sind. Ich konnte einfach nicht verstehen, warum ich so viele Diskussionen fand, wo Leute gegen Properties eintraten.
Ein guter Grund für schreibgeschützte Eigenschaften sind Werte, die berechnet werden. In diesem Fall gibt es keine Variable zum Exportieren.
Zum Beispiel
%Vor%In diesem Fall ist es fraglich, ob _birthday als Eigenschaft oder als Feld angezeigt werden soll. Für andere berechnete Werte wie Age ist die einzige Möglichkeit, sie als Variable verfügbar zu machen, sie im Objekt zu speichern. In diesem Fall speichert eine zusätzliche Variable für Age im Wesentlichen redundante Informationen. Wenn sie als berechnete Eigenschaft verfügbar gemacht wird, entsteht ein geringer Overhead und es werden keine redundanten Daten gespeichert.
Grund # 1 = Eigenschaften können in der Datenbindung verwendet werden. Methoden können nicht.
Grund # 2 = Beim Debuggen des Überwachungsfensters werden die Eigenschaften automatisch angezeigt / das Objekt wird erweitert. Methoden werden nicht automatisch auf diese Weise beobachtet.
Ich erinnere mich, dass ich gelesen habe, dass die Eigenschaft read den Objektstatus nicht ändern sollte. Ich denke, das ist eine gute Übung, vor allem wenn man den Grund Nr. 2 betrachtet. Sobald Sie ein Objekt beobachten und es in der Uhr erweitern, kann der Objektstatus geändert werden, was das Debugging erschwert.
Auch wenn ein teures Objekt durch einen Unfall gebunden ist, kann es ernsthafte Leistungsprobleme verursachen. (Attribute können Eigenschaften aus der Datenbindung "verbergen", aber wenn Sie sie einfach machen, müssen Sie sich keine Gedanken darüber machen.)
Eigenschaften sind Annehmlichkeiten für die Fensterentwicklung. Sie werden in Designern usw. unterschiedlich verwendet.
(Ich stelle manchmal nur einige Variablen auf. Aber ich benenne sie wie eine Eigenschaft. Also statt
Ganzzahl mZähler = 0;
Ich mache es nur
Ganzzahlzähler = 0 ;.
Wenn ich zu einem späteren Zeitpunkt "zusätzliche Sachen" machen muss, erstelle ich die Eigenschaft mit dem gleichen Namen und benenne die Variable in mCounter um. Zugegeben, das ist Faulheit meinerseits und ich empfehle es nicht wirklich. Einfach in eine Eigenschaft einfügen.)
Es gibt mehr Eigenschaften als automatische Eigenschaften. Wenn du es tust:
%Vor%Dann ist es wirklich nicht anders als
%Vor%Aber der große Vorteil von ersterem ist, dass Sie es später in
ändern können %Vor%Und anderer Code, der Ihr Objekt verwendet, würde ohne Neukompilierung funktionieren. Wenn Sie stattdessen ein öffentliches Feld verwendet hätten, müsste der Client-Code neu kompiliert werden, wenn Sie ihn jemals von einem Feld in eine Eigenschaft ändern möchten.
Eigenschaften sind ein praktischer Ersatz für methodenbasierte Operationen. Es gibt keinen funktionalen Unterschied zwischen einem Eigenschaft-Getter-Setter und einer Methode, die die gleichen Aktionen ausführt; Wenn Sie sich IL ansehen, sehen Sie, dass die Eigenschaften-Accessoren durch Methoden "get" und / oder "set" ersetzt werden.
Der stärkste Grund für die Verwendung von Eigenschaften gegenüber dem Zugriff auf Variablen ist die Kapselung. Angenommen, Sie schreiben eine Bibliothek und geben eine IsBlue -Variable aus. Du verteilst die Bibliothek, jeder liebt und benutzt sie. Jetzt ist es Zeit für Version 2, und Sie möchten etwas tun, wenn der Benutzer IsBlue setzt - vielleicht eine Überprüfung durchführen, vielleicht etwas zwischenspeichern. Um dies zu tun, müssen Sie die Variable in eine Eigenschaft oder Methode konvertieren und dort einchecken. Jetzt haben Sie Ihren gesamten Client-Code gebrochen - die Variable, auf die Sie zugegriffen haben, ist nicht mehr vorhanden. Wenn Sie es ursprünglich als Eigenschaft implementiert hätten, hätten Sie einfach den Code der Eigenschaft ändern und die Binärkompatibilität beibehalten können.
"Cache-Daten - & gt; Öffentliche Variable" - schlechte Idee. Dadurch könnte eine andere Klasse die zwischengespeicherten Daten ändern. Darüber hinaus ist die Berechnung der Daten für das Caching möglicherweise teuer: Wenn Sie eine schreibgeschützte Eigenschaft verwenden, können Sie die Berechnung verschieben, bis auf die Eigenschaft zugegriffen wird.
Es wird als schlechte Übung angesehen, Ihre Variable von Ihrer Klasse auszusetzen. Plus, wenn Sie die Struktur Ihres Objekts ändern, aber Ihre Eigenschaften intakt bleiben, hat dies keinen Einfluss auf den Code, der Ihre Klasse verwendet.
Tags und Links .net function properties