Warum sollte ich die Verwendung von Eigenschaften in C# vermeiden?

Question

In seinem hervorragenden Buch CLR Via C# sagt Jeffrey Richter, dass er Eigenschaften nicht mag und empfiehlt, sie nicht zu verwenden. Er gab einige Gründe an, aber ich verstehe sie nicht wirklich. Kann mir jemand erklären, warum ich Eigenschaften verwenden sollte oder nicht? Ändert sich das in C# 3.0, mit automatischen Eigenschaften?

Als Referenz habe ich die Stellungnahmen von Jeffrey Richter hinzugefügt:

- Eine Eigenschaft kann schreibgeschützt oder schreibgeschützt sein; der Feldzugriff ist immer lesbar und schreibbar. Wenn Sie eine Eigenschaft definieren, ist es am besten, sowohl Get- als auch Set-Accessor-Methoden anzubieten.

- Eine Eigenschaftsmethode kann eine Ausnahme auslösen; ein Feldzugriff löst nie eine Ausnahme aus.

- Eine Eigenschaft kann nicht als out- oder ref-Parameter an eine Methode übergeben werden, ein Feld schon. Für Beispiel: Der folgende Code lässt sich nicht kompilieren:

using System;
public sealed class SomeType
{
   private static String Name 
   {
     get { return null; }
     set {}
   }
   static void MethodWithOutParam(out String n) { n = null; }
   public static void Main()
   {
      // For the line of code below, the C# compiler emits the following:
      // error CS0206: A property or indexer may not
      // be passed as an out or ref parameter
      MethodWithOutParam(out Name);
   }
}

- Die Ausführung einer Eigenschaftsmethode kann lange dauern; der Feldzugriff wird immer sofort abgeschlossen. Ein häufiger Grund für die Verwendung von Eigenschaften ist die Synchronisierung von Threads, die den Thread für immer anhalten kann. Daher sollte eine Eigenschaft nicht verwendet werden, wenn eine Thread-Synchronisierung erforderlich ist. In dieser Situation ist eine Methode vorzuziehen. Wenn auf Ihre Klasse auch aus der Ferne zugegriffen werden kann auf Ihre Klasse aus der Ferne zugegriffen werden kann (z. B. wenn Ihre Klasse von System.MashalByRefObject abgeleitet ist), wird der Aufruf der Eigenschaftsmethode sehr langsam sein, und daher ist eine Methode einer Eigenschaft. Meiner Meinung nach sollten von MarshalByRefObject abgeleitete Klassen niemals Eigenschaften verwenden.

- Wenn eine Eigenschaftsmethode mehrmals hintereinander aufgerufen wird, kann sie jedes Mal einen anderen Wert zurückgeben jedes Mal einen anderen Wert zurückgeben; ein Feld gibt jedes Mal denselben Wert zurück. Die Klasse System.DateTime hat eine schreibgeschützte Now-Eigenschaft, die das aktuelle Datum und die aktuelle Uhrzeit zurückgibt. Jedes Mal, wenn Sie diese Eigenschaft abfragen, wird ein anderer Wert zurückgegeben. Dies ist ein Fehler, und Microsoft wünscht, dass sie die Klasse reparieren könnte, indem sie Now zu einer Methode statt zu einer Eigenschaft macht.

- Eine Eigenschaftsmethode kann beobachtbare Nebeneffekte haben, ein Feldzugriff hat das nie. In anderen Ein Benutzer eines Typs sollte also in der Lage sein, verschiedene von einem Typ definierte Eigenschaften in beliebiger Reihenfolge zu setzen, ohne ein anderes Verhalten des Typs zu bemerken.

- Eine Eigenschaftsmethode kann zusätzlichen Speicher benötigen oder einen Verweis auf etwas zurückgeben zurück, das eigentlich nicht zum Zustand des Objekts gehört, so dass eine Änderung des zurückgegebenen Objekts keine Auswirkungen auf das ursprüngliche Objekt; die Abfrage eines Feldes gibt immer einen Verweis auf ein Objekt zurück, das garantiert Teil des Zustands des ursprünglichen Objekts ist. Die Arbeit mit einer Eigenschaft, die eine Kopie zurückgibt, kann für Entwickler sehr verwirrend sein, und diese Eigenschaft ist häufig nicht dokumentiert.

Answer 1

Es gibt eine Zeit, in der ich in Erwägung ziehe, Eigenschaften nicht zu verwenden, und das ist beim Schreiben von .Net Compact Framework-Code. Der CF JIT-Compiler führt nicht dieselbe Optimierung durch wie der Desktop JIT-Compiler und optimiert keine einfachen Eigenschaftszugriffsfunktionen, so dass in diesem Fall das Hinzufügen einer einfachen Eigenschaft zu einer geringfügigen Aufblähung des Codes gegenüber der Verwendung eines öffentlichen Feldes führt. Normalerweise wäre dies kein Problem, aber in der Welt des Compact Frameworks muss man fast immer mit engen Speicherbeschränkungen rechnen, so dass selbst kleine Einsparungen wie diese zählen.

Answer 2

Sie sollten nicht darauf verzichten, sie zu verwenden, aber Sie sollten sie aus den von anderen Redakteuren genannten Gründen mit Bedacht und Sorgfalt einsetzen.

Ich habe einmal eine Eigenschaft mit dem Namen "Customers" gesehen, die intern einen prozessfremden Aufruf an eine Datenbank öffnete und die Kundenliste las. Der Client-Code hatte ein "for (int i to Customers.Count)", das bei jeder Iteration und für den Zugriff auf den ausgewählten Kunden einen separaten Aufruf an die Datenbank verursachte. Dies ist ein ungeheuerliches Beispiel, das den Grundsatz veranschaulicht, die Eigenschaft sehr leicht zu halten - selten mehr als einen internen Feldzugriff.

Ein Argument FÜR die Verwendung von Eigenschaften ist, dass sie es Ihnen ermöglichen, den eingestellten Wert zu überprüfen. Ein weiteres Argument ist, dass der Wert der Eigenschaft ein abgeleiteter Wert und nicht ein einzelnes Feld sein kann, z. B. TotalValue = amount * quantity.

Answer 3

Ich persönlich verwende Eigenschaften nur bei der Erstellung einfacher Get-/Set-Methoden. Ich weiche davon ab, wenn es um komplizierte Datenstrukturen geht.

Answer 4

Ich habe sein Buch nicht gelesen, aber ich stimme ihm zu. Es ist ein ziemlicher Widerspruch zu dem üblichen Paradigma. Sie sehen aus wie ein Feld, haben aber viele Nebeneffekte. Ausnahmen, Leistung, Nebeneffekte, Unterschied zwischen Lese- und Schreibzugriff, usw. Wenn Sie sich für Lesbarkeit und Zuverlässigkeit interessieren, sollten Sie sich auch dafür interessieren.

Meiner Erfahrung nach habe ich nie etwas von Eigenschaften profitiert und hatte nur Lust, sie zu nutzen, wenn ich faul war. Aber oft habe ich Leute erlebt, die Eigenschaften so verwenden, als wären es Felder, und damit versehentlich alle möglichen Probleme verursachen. Ich habe lange Zeit professionell an vielen Sprachen gearbeitet und habe sie nie gebraucht, nicht ein einziges Mal. Natürlich könnten andere Leute sie nützlich finden, und das ist auch gut so. Es kommt auf Ihren Anwendungsfall an und darauf, worauf Sie Wert legen.

Ich persönlich glaube, dass es sich dabei nur um "Funktionen" handelt, die man wählen. zu verwenden oder nicht.

Answer 5

Der Aufruf von Methoden anstelle von Eigenschaften verringert die Lesbarkeit des aufrufenden Codes erheblich. In J# zum Beispiel war die Verwendung von ADO.NET ein Alptraum, weil Java keine Eigenschaften und Indexer (die im Wesentlichen Eigenschaften mit Argumenten sind) unterstützt. Der daraus resultierende Code war extrem hässlich, mit leeren Klammern Methodenaufrufe ganz über den Platz.

Die Unterstützung für Eigenschaften und Indexer ist einer der grundlegenden Vorteile von C# gegenüber Java.