Wie das neue field-Schlüsselwort C#-Eigenschaften verbessert

Overview of C# Properties and the Upgrade in C# 14

Tim beginnt mit dem Hinweis, dass es ein großes Upgrade für C#-Eigenschaften in C# 14 gibt. Er macht klar, dass der Fokus des Videos auf dem neuen field-Schlüsselwort liegt, das beeinflusst, wie automatische Eigenschaften intern funktionieren. Tim erwähnt auch, dass C# 14 zusammen mit .NET 10 und Visual Studio 2026 ausgeliefert wird, obwohl das Feature selbst in früheren .NET-Versionen funktionieren kann.

Er rahmt das Video als eine schnelle, konzentrierte Erklärung, die darauf abzielt, eine spezifische Frage zu beantworten: Wie nutzen wir diese neue Funktion im realen Code? Dies setzt den Ton für eine praktische Durchführung anstelle einer theoretischen Diskussion über die Definition von Eigenschaften.

Das Person Klassenbeispiel und Automatische Eigenschaften

Um ca. 0:23 stellt Tim eine Konsolenanwendung mit einer einfachen öffentlichen Klasse Person vor. Diese Person-Klasse enthält mehrere öffentliche Eigenschaften, einschließlich:

• public string Vorname

• public string Nachname

• public int Alter

Tim erklärt, dass dies automatisch implementierte Eigenschaften sind (auch automatisch implementierte Eigenschaften genannt). Es gibt keine sichtbaren privaten Variablen oder privaten Felder, weil der Compiler automatisch ein Hintergrundfeld im Hintergrund erstellt.

Er beinhaltet auch eine Demo-Eigenschaft, die nicht automatisch implementiert ist. Stattdessen verwendet es ein privates String-Backup-Feld (_demo) und exponiert eine schreibgeschützte Eigenschaft, die nur einen get-Accessor verwendet. Dieser Unterschied wird später im Video wichtig.

Verwendung von Eigenschaften in Program.cs

Tim wechselt dann in die Klasse Program und zeigt, wie das Person-Objekt innerhalb von public static void main (oder static void main string args, konzeptionell) erstellt wird. Er instanziiert eine neue Person mithilfe von:

new Person { FirstName = "Tim", LastName = "Corey" }

Tim weist darauf hin, dass Eigenschaften den Zugriff außerhalb der Klasse ermöglichen und dennoch private Datenmitglieder verbergen. Er ruft Werte wie Nachname, Alter und Demo ab und zeigt, wie Eigenschaften beim Zugriff wie Felder erscheinen, obwohl sie tatsächlich spezielle Methoden im Hintergrund sind.

Das Problem mit ungültigen Werten in Automatischen Eigenschaften

Um etwa 1:23 weist Tim absichtlich einen ungültigen Wert zu:

person.Nachname = null;

Obwohl LastName erforderlich ist und nicht als null markiert ist, funktioniert die Zuweisung zur Laufzeit immer noch. Tim erklärt, dass automatische Eigenschaften nicht automatisch gegen ungültige Werte schützen. Der Compiler warnt Sie, aber die set-Methode akzeptiert den Wert dennoch.

Dies zeigt ein zentrales Problem mit automatisch implementierten Eigenschaften: obwohl sie prägnant sind, bieten sie keinen eingebauten Mechanismus zur Validierung. Ungültige Daten können passieren und heimlich Annahmen brechen.

Die Traditionelle Volle Eigenschaft mit Backup-Feld

Um etwa 2:58 zeigt Tim, was Entwickler in früheren Versionen von C# taten. Er wandelt LastName in eine voll implementierte Eigenschaft mit:

• Einem privaten String-Backup-Feld

• Einem set-Accessor, der den Eigenschaftswert überprüft

• Einer Ausnahme, die bei ungültigen Werten ausgelöst wird

Dieser Ansatz gibt vollständige Kontrolle über die Eigenschafts-Accessor, aber Tim betont, wie umfangreich sie wird. Die Eigenschaft nimmt jetzt mehrere Zeilen in Anspruch, verglichen mit der einzeiligen Syntax der automatischen Eigenschaften.

Er erklärt auch, dass der Wechsel von einer automatischen Eigenschaft zu einer vollständigen Eigenschaft den bestehenden Code nicht bricht, da der Eigenschaftsname, die Zugänglichkeitsebene und der externe Gebrauch gleich bleiben.

Das Neue field-Schlüsselwort als Mittelweg

Um 4:19 führt Tim die entscheidende Verbesserung in C# 14 ein. Anstatt die gesamte Eigenschaft zu schreiben, behält er die automatische Eigenschaftsstruktur bei und ändert nur den set-Accessor mit dem field-Schlüsselwort.

Tim erklärt, dass field das vom Compiler generierte private Feld darstellt, das normalerweise verborgen bleibt. Durch die Zuweisung von field = value können Entwickler den Eigenschaftswert abfangen und validieren, ohne ihre eigene private Variable deklarieren zu müssen.

Dies bewahrt die gleiche Syntax, an die Entwickler gewöhnt sind, und fügt Flexibilität hinzu. Tim betont, dass dies den Code reduziert und dennoch Validierungslogik ermöglicht, wodurch er zwischen automatischen und vollständigen Eigenschaften steht.

Scoped Backup-Felder und Eigenschaftsisolierung

Tim erklärt, dass das field-Schlüsselwort auf die Eigenschaft beschränkt ist, in der es erscheint. Jede Eigenschaft erhält ihr eigenes Backup-Feld, und es besteht kein Risiko von Ineffektionen zwischen den Eigenschaften.

Wenn dieselbe Syntax in einer anderen Eigenschaft verwendet wird – beispielsweise FirstName – bezieht sie sich auf das eigene Backup-Feld dieser Eigenschaft. Dies macht die Funktion vorhersehbar und sicher über mehrere öffentliche Eigenschaften hinweg.

Validierung Numerischer Eigenschaften wie Alter

Um ca. 6:16 wendet Tim denselben Ansatz auf eine öffentliche int-Eigenschaft Age an. Er weist einen ungültigen negativen Wert zu und erklärt, warum er nicht erlaubt sein sollte.

Statt eine Ausnahme auszulösen, zeigt Tim eine andere Strategie: ungültige Werte zu ignorieren. Die set-Methode überprüft, ob der Wert in einem gültigen Bereich liegt, bevor er ihm field zuweist.

Dies zeigt, dass der neue Ansatz gleichermaßen gut für private int age, numerische Validierung und bedingte Logik funktioniert – alles, ohne die Eigenschaft in eine vollständige Implementierung umzuwandeln.

Naming-Konflikte mit dem field-Schlüsselwort

Tim bespricht dann einen möglichen Grenzfall: Namenskonflikte. Wenn eine Klasse bereits eine Variable namens field enthält, kann dies mit dem neuen Schlüsselwort innerhalb von Eigenschaften im Konflikt stehen.

Er zeigt, wie dies Verwirrung und unerwartetes Verhalten verursacht. Tim erklärt, dass die Lösung darin besteht, die Variable explizit mit this.field oder @field zu referenzieren. Dies unterscheidet den Variablennamen vom Schlüsselwort des Backup-Felds.

Tim empfiehlt ausdrücklich, solche Variablen umzubenennen, als eine gute Praxis, besonders beim Aktualisieren bestehender Codebasen.

Wo Namenskonflikte nicht zutreffen

Tim klärt, dass das field-Schlüsselwort nur innerhalb von Eigenschafts-Accessoren eine besondere Bedeutung hat. In Konstruktoren, Methoden oder anderen Teilen der Klasse verhält sich field wie eine normale Variable.

Diese Unterscheidung hilft Entwicklern zu verstehen, wann das vom Compiler generierte Backup-Feld existiert und wann nicht.

Abschließende Gedanken von Tim Corey

Tim schließt sein Video ab, indem er zusammenfasst, wie das neue field-Schlüsselwort funktioniert und warum es Eigenschaften in C# verbessert. Es erlaubt Entwicklern, weiterhin automatische Eigenschaften zu nutzen, während sie Validierung, Kontrolle und Klarheit hinzufügen.

Er ermutigt die Zuschauer, das Feature auszuprobieren, zu erkunden, wie es in ihren Codierungsstil passt, und sorgfältig über Namenskonventionen nachzudenken. Tim beendet das Video, indem er bekräftigt, dass diese Änderung Eigenschaften ausdrucksstärker macht, ohne unnötige Komplexität hinzuzufügen.