Obwohl Felder und Eigenschaften einander ähnlich zu sein scheinen, sind sie zwei völlig unterschiedliche Sprachelemente.
Felder sind der einzige Mechanismus zum Speichern von Daten auf Klassenebene. Felder sind konzeptionell Variablen im Klassenbereich. Wenn Sie einige Daten in Instanzen Ihrer Klassen (Objekte) speichern möchten, müssen Sie Felder verwenden. Es gibt keine andere Wahl. Eigenschaften können keine Daten speichern, obwohl sie möglicherweise dazu in der Lage sind. Siehe unten.
Eigenschaften hingegen speichern niemals Daten. Sie sind nur die Methodenpaare (get und set), die auf ähnliche Weise wie Felder syntaktisch aufgerufen werden können, und in den meisten Fällen greifen sie auf (zum Lesen oder Schreiben) Felder zu, was zu Verwirrung führt. Da Eigenschaftsmethoden jedoch (mit einigen Einschränkungen wie dem festen Prototyp) reguläre C # -Methoden sind, können sie alle regulären Methoden ausführen. Dies bedeutet, dass sie 1000 Codezeilen haben können, Ausnahmen auslösen, andere Methoden aufrufen, sogar virtuell, abstrakt oder überschrieben sein können. Das Besondere an Eigenschaften ist die Tatsache, dass der C # -Compiler einige zusätzliche Metadaten in Assemblys speichert, mit denen nach bestimmten Eigenschaften gesucht werden kann - eine weit verbreitete Funktion.
Das Abrufen und Festlegen von Eigenschaftsmethoden umfasst die folgenden Prototypen.
PROPERTY_TYPE get();
void set(PROPERTY_TYPE value);
Dies bedeutet, dass Eigenschaften durch Definieren eines Felds und zweier entsprechender Methoden "emuliert" werden können.
class PropertyEmulation
{
private string MSomeValue;
public string GetSomeValue()
{
return(MSomeValue);
}
public void SetSomeValue(string value)
{
MSomeValue=value;
}
}
Eine solche Eigenschaftsemulation ist typisch für Programmiersprachen, die keine Eigenschaften unterstützen - wie Standard-C ++. In C # sollten Sie immer Eigenschaften bevorzugen, um auf Ihre Felder zugreifen zu können.
Da nur die Felder Daten speichern können, bedeutet dies, dass mehr Feldklassen enthalten und mehr Speicherobjekte dieser Klasse verbraucht werden. Wenn Sie jedoch einer Klasse neue Eigenschaften hinzufügen, werden Objekte dieser Klasse nicht größer. Hier ist das Beispiel.
class OneHundredFields
{
public int Field1;
public int Field2;
...
public int Field100;
}
OneHundredFields Instance=new OneHundredFields() // Variable 'Instance' consumes 100*sizeof(int) bytes of memory.
class OneHundredProperties
{
public int Property1
{
get
{
return(1000);
}
set
{
// Empty.
}
}
public int Property2
{
get
{
return(1000);
}
set
{
// Empty.
}
}
...
public int Property100
{
get
{
return(1000);
}
set
{
// Empty.
}
}
}
OneHundredProperties Instance=new OneHundredProperties() // !!!!! Variable 'Instance' consumes 0 bytes of memory. (In fact a some bytes are consumed becasue every object contais some auxiliarity data, but size doesn't depend on number of properties).
Obwohl Eigenschaftsmethoden alles können, dienen sie in den meisten Fällen als Möglichkeit, auf die Felder von Objekten zuzugreifen. Wenn Sie ein Feld für andere Klassen zugänglich machen möchten, haben Sie zwei Möglichkeiten.
- Felder öffentlich machen - nicht ratsam.
- Eigenschaften verwenden.
Hier ist eine Klasse, die öffentliche Felder verwendet.
class Name
{
public string FullName;
public int YearOfBirth;
public int Age;
}
Name name=new Name();
name.FullName="Tim Anderson";
name.YearOfBirth=1979;
name.Age=40;
Obwohl der Code aus gestalterischer Sicht vollkommen gültig ist, weist er mehrere Nachteile auf. Da Felder sowohl gelesen als auch geschrieben werden können, können Sie den Benutzer nicht daran hindern, in Felder zu schreiben. Sie können ein readonlySchlüsselwort anwenden , aber auf diese Weise müssen Sie schreibgeschützte Felder nur im Konstruktor initialisieren. Darüber hinaus hindert Sie nichts daran, ungültige Werte in Ihren Feldern zu speichern.
name.FullName=null;
name.YearOfBirth=2200;
name.Age=-140;
Der Code ist gültig, alle Zuweisungen werden ausgeführt, obwohl sie unlogisch sind. Agehat einen negativen Wert, YearOfBirthist weit in der Zukunft und entspricht nicht dem Alter und FullNameist null. Mit Feldern können Sie Benutzer nicht daran hindern class Name, solche Fehler zu machen.
Hier ist ein Code mit Eigenschaften, der diese Probleme behebt.
class Name
{
private string MFullName="";
private int MYearOfBirth;
public string FullName
{
get
{
return(MFullName);
}
set
{
if (value==null)
{
throw(new InvalidOperationException("Error !"));
}
MFullName=value;
}
}
public int YearOfBirth
{
get
{
return(MYearOfBirth);
}
set
{
if (MYearOfBirth<1900 || MYearOfBirth>DateTime.Now.Year)
{
throw(new InvalidOperationException("Error !"));
}
MYearOfBirth=value;
}
}
public int Age
{
get
{
return(DateTime.Now.Year-MYearOfBirth);
}
}
public string FullNameInUppercase
{
get
{
return(MFullName.ToUpper());
}
}
}
Die aktualisierte Version der Klasse bietet die folgenden Vorteile.
FullNameund YearOfBirthwerden auf ungültige Werte überprüft.Ageist nicht schreibbar. Es ist ab dem YearOfBirthlaufenden Jahr aufgerufen .- Eine neue Eigenschaft
FullNameInUppercasewird FullNamein UPPER CASE konvertiert . Dies ist ein wenig erfundenes Beispiel für die Verwendung von Eigenschaften, bei dem Eigenschaften häufig verwendet werden, um Feldwerte in dem Format darzustellen, das für den Benutzer besser geeignet ist - beispielsweise unter Verwendung des aktuellen Gebietsschemas für eine bestimmte Formatnummer DateTime.
Darüber hinaus können Eigenschaften als virtuell oder überschrieben definiert werden - einfach weil es sich um reguläre .NET-Methoden handelt. Für solche Eigenschaftsmethoden gelten dieselben Regeln wie für reguläre Methoden.
C # unterstützt auch Indexer, bei denen es sich um Eigenschaften handelt, die in Eigenschaftsmethoden einen Indexparameter haben. Hier ist das Beispiel.
class MyList
{
private string[] MBuffer;
public MyList()
{
MBuffer=new string[100];
}
public string this[int Index]
{
get
{
return(MBuffer[Index]);
}
set
{
MBuffer[Index]=value;
}
}
}
MyList List=new MyList();
List[10]="ABC";
Console.WriteLine(List[10]);
Seit C # 3.0 können Sie automatische Eigenschaften definieren. Hier ist das Beispiel.
class AutoProps
{
public int Value1
{
get;
set;
}
public int Value2
{
get;
set;
}
}
Obwohl es class AutoPropsnur Eigenschaften enthält (oder so aussieht), kann es 2 Werte speichern und die Größe von Objekten dieser Klasse entspricht sizeof(Value1)+sizeof(Value2)= 4 + 4 = 8 Bytes.
Der Grund dafür ist einfach. Wenn Sie eine automatische Eigenschaft definieren, generiert der C # -Compiler automatischen Code, der ein verstecktes Feld und eine Eigenschaft mit Eigenschaftsmethoden enthält, die auf dieses versteckte Feld zugreifen. Hier wird der Code-Compiler erstellt.
Hier ist ein Code, der von ILSpy aus einer kompilierten Assembly generiert wird . Klasse enthält generierte versteckte Felder und Eigenschaften.
internal class AutoProps
{
[CompilerGenerated]
[DebuggerBrowsable(DebuggerBrowsableState.Never)]
private int <Value1>k__BackingField;
[CompilerGenerated]
[DebuggerBrowsable(DebuggerBrowsableState.Never)]
private int <Value2>k__BackingField;
public int Value1
{
[CompilerGenerated]
get
{
return <Value1>k__BackingField;
}
[CompilerGenerated]
set
{
<Value1>k__BackingField = value;
}
}
public int Value2
{
[CompilerGenerated]
get
{
return <Value2>k__BackingField;
}
[CompilerGenerated]
set
{
<Value2>k__BackingField = value;
}
}
}
Wie Sie sehen, verwendet der Compiler die Felder weiterhin zum Speichern der Werte, da Felder die einzige Möglichkeit sind, Werte in Objekten zu speichern.
Wie Sie sehen können, sind Eigenschaften und Felder zwar eine ähnliche Verwendungssyntax, aber sehr unterschiedliche Konzepte. Selbst wenn Sie automatische Eigenschaften oder Ereignisse verwenden - versteckte Felder werden vom Compiler generiert, in dem die realen Daten gespeichert werden.
Wenn Sie einen Feldwert für die Außenwelt zugänglich machen müssen (Benutzer Ihrer Klasse), verwenden Sie keine öffentlichen oder geschützten Felder. Felder sollten immer als privat markiert werden. Mit den Eigenschaften können Sie Wertprüfungen, Formatierungen, Konvertierungen usw. durchführen und Ihren Code im Allgemeinen sicherer, lesbarer und erweiterbarer für zukünftige Änderungen machen.