Comment le nouveau mot-clé field améliore les propriétés C#

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

Tim commence par expliquer qu'il y a une grande amélioration des propriétés C# dans C# 14. Il précise que le sujet de la vidéo est le nouveau mot-clé field, qui affecte la manière dont les propriétés automatiques fonctionnent en interne. Tim mentionne également que C# 14 est livré avec .NET 10 et Visual Studio 2026, bien que la fonctionnalité elle-même puisse fonctionner dans des versions antérieures de .NET.

Il cadre la vidéo comme une explication rapide et ciblée, conçue pour répondre à une question spécifique : comment utilisons-nous cette nouvelle fonctionnalité dans un vrai code ? Cela établit le ton pour une visite guidée pratique plutôt qu'une discussion théorique sur la définition des propriétés.

Exemple de Classe Personne et Propriétés Automatiques

Vers 0:23, Tim introduit une application console avec une simple classe publique Personne. Cette classe personne contient plusieurs propriétés publiques, y compris :

• public string Prénom

• public string Nom

• public int Âge

Tim explique que ce sont des propriétés auto-implémentées (également appelées propriétés implémentées automatiquement). Il n'y a pas de variables privées ou de champs privés visibles parce que le compilateur crée automatiquement un champ de sauvegarde en arrière-plan.

Il inclut également une propriété Demo qui n'est pas auto-implémentée. Au lieu de cela, elle utilise un champ de sauvegarde string privé (_demo) et expose une propriété en lecture seule en utilisant seulement un accesseur get. Ce contraste devient important plus tard dans la vidéo.

Utilisation des Propriétés dans Program.cs

Tim passe ensuite dans la classe Programme et montre comment l'objet Personne est créé à l'intérieur de la méthode public static void main (ou static void main string args, conceptuellement). Il instancie une nouvelle personne en utilisant :

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

Tim souligne que les propriétés permettent l'accès en dehors de la classe tout en cachant les membres de données privés. Il récupère des valeurs comme le nom de famille, l'âge et la démo, montrant comment les propriétés apparaissent comme de simples champs lorsqu'elles sont accédées, même si elles sont en fait des méthodes spéciales en coulisses.

Le Problème des Valeurs Invalides dans les Propriétés Automatiques

Vers 1:23, Tim attribue délibérément une valeur invalide :

person.LastName = null;

Même si LastName est requis et non marqué nul, l'attribution fonctionne toujours à l'exécution. Tim explique que les propriétés automatiques ne protègent pas automatiquement contre les valeurs invalides. Le compilateur vous avertit, mais la méthode set accepte toujours la valeur.

Cela démontre un problème clé avec les propriétés auto-implémentées : bien qu'elles soient concises, elles ne fournissent pas de moyen intégré d'ajouter une validation. Les données invalides peuvent passer et briser silencieusement les hypothèses.

La Propriété Complète Traditionnelle avec Champ de Sauvegarde

Vers 2:58, Tim montre ce que les développeurs faisaient dans les versions antérieures de C#. Il convertit LastName en une propriété entièrement implémentée avec :

• Un champ de soutien de type string privé

• Un accesseur set qui vérifie la valeur de la propriété

• Une exception levée pour des valeurs invalides

Cette approche offre un contrôle total sur les accesseurs de propriété, mais Tim souligne à quel point elle devient verbeuse. La propriété prend désormais plusieurs lignes, par rapport à la syntaxe d'une seule ligne des propriétés auto.

Il explique également que passer d'une propriété auto à une propriété complète ne casse pas le code existant, puisque le nom de propriété, le niveau d'accessibilité et l'utilisation externe restent les mêmes.

Le nouveau mot-clé field comme un juste milieu

À 4:19, Tim présente l'amélioration clé de C# 14. Au lieu d'écrire une propriété complète, il conserve la structure de la propriété auto et modifie seulement l'accesseur set à l'aide du mot-clé field.

Tim explique que field représente le champ privé généré par le compilateur qui reste normalement caché. En assignant field = value, les développeurs peuvent désormais intercepter et valider la valeur de la propriété sans déclarer leur propre variable privée.

Cela préserve la même syntaxe à laquelle les développeurs sont habitués tout en ajoutant de la flexibilité. Tim souligne que cela réduit le code tout en permettant toujours une logique de validation, le plaçant entre les propriétés auto et les propriétés complètes.

Champs de soutien déterminés et isolation des propriétés

Tim explique que le champ field est limité à la propriété dans laquelle il apparaît. Chaque propriété obtient son propre champ de soutien, et il n'y a aucun risque d'interférence inter-propriété.

Si la même syntaxe est utilisée dans une autre propriété - telle que FirstName - elle se réfère au champ de soutien propre à cette propriété. Cela rend la fonctionnalité prévisible et sûre à utiliser avec plusieurs propriétés publiques.

Validation de propriétés numériques comme Age

Vers 6:16, Tim applique la même approche à une propriété publique int Age. Il assigne une valeur négative invalide et explique pourquoi elle ne devrait pas être autorisée.

Au lieu de lancer une exception, Tim montre une stratégie différente : ignorer les valeurs invalides. La méthode set vérifie si la valeur est dans une plage valide avant de l'assigner au champ.

Cela démontre que la nouvelle approche fonctionne tout aussi bien pour l'entier privé age, la validation numérique et la logique conditionnelle - tout cela sans convertir la propriété en une implémentation complète.

Conflits de dénomination avec le mot-clé field

Tim aborde ensuite un cas limite potentiel : les conflits de nommage. Si une classe contient déjà une variable nommée field, elle peut entrer en conflit avec le nouveau mot-clé à l'intérieur des propriétés.

Il démontre comment cela peut causer de la confusion et un comportement inattendu. Tim explique que la solution est de référencer explicitement la variable en utilisant this.field ou @field. Cela distingue le nom de la variable du mot-clé field.

Tim recommande fortement de renommer ces variables comme une bonne pratique, surtout lors de la mise à jour des bases de code existantes.

Où les conflits de noms ne s'appliquent pas

Tim clarifie que le mot-clé field n'a de signification spéciale qu'à l'intérieur des accesseurs de propriété. Dans les constructeurs, méthodes, ou d'autres parties de la classe, field se comporte comme une variable normale.

Cette distinction aide les développeurs à comprendre quand le champ de soutien généré par le compilateur existe et quand ce n'est pas le cas.

Réflexions finales de Tim Corey

Tim conclut sa vidéo en résumant comment le nouveau mot-clé field fonctionne et pourquoi il améliore les propriétés en C#. Il permet aux développeurs de continuer à utiliser des propriétés automatiques tout en ajoutant validation, contrôle et clarté.

Il encourage les spectateurs à essayer la fonctionnalité, explorer comment elle s'intègre dans leur style de codage et réfléchir attentivement aux conventions de nommage. Tim termine la vidéo en renforçant que ce changement rend les propriétés plus expressives sans ajouter de complexité inutile.