Propriétés automatiques C# 3.0 — utiles ou non ?[fermé]

Question

Note:Ceci a été publié lorsque je démarrais C#.Avec mes connaissances de 2014, je peux vraiment dire que les propriétés automatiques sont parmi les meilleures choses qui soient jamais arrivées au langage C#.

J'ai l'habitude de créer mes propriétés en C# en utilisant un champ privé et un champ public :

private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Maintenant avec .FILET 3.0, nous avons des propriétés automatiques :

public string Title { get; set; }

Je sais qu'il s'agit plutôt d'une question philosophique/subjective, mais y a-t-il une raison d'utiliser ces propriétés automatiques, sauf en sauvegardant cinq lignes de code pour chaque champ ?Mon reproche personnel est que ces propriétés me cachent des choses, et je ne suis pas un grand fan de magie noire.

En fait, le champ privé caché n'apparaît même pas dans le débogueur, ce qui est correct étant donné que les fonctions get/set ne font rien.Mais lorsque je veux réellement implémenter une logique getter/setter, je dois quand même utiliser la paire privé/public.

Je vois l'avantage d'économiser beaucoup de code (une ligne contre six) sans perdre la possibilité de modifier la logique getter/setter plus tard, mais là encore, je peux déjà le faire en déclarant simplement un champ public "Titre de chaîne publique" sans le besoin du { obtenir ;ensemble;} bloc, économisant ainsi encore plus de code.

Alors, qu'est-ce qui me manque ici ?Pourquoi quelqu’un voudrait-il réellement utiliser les propriétés automatiques ?

Answer 1

Nous les utilisons tout le temps dans Stack Overflow.

Vous pourriez également être intéressé par une discussion sur Propriétés vs.Variables publiques.À mon humble avis, c'est vraiment à cela qu'il s'agit d'une réaction, et dans ce but, c'est génial.

Answer 2

Oui juste enregistrer le code.C'est beaucoup plus facile à lire quand vous en avez beaucoup.Ils sont plus rapides à écrire et plus faciles à maintenir.Enregistrer le code est toujours un bon objectif.

Vous pouvez définir différentes étendues :

public string PropertyName { get; private set; }

De sorte que la propriété ne peut être modifiée qu’à l’intérieur de la classe.Ce n'est pas vraiment immuable car vous pouvez toujours accéder au passeur privé par réflexion.

Depuis C#6, vous pouvez également créer de vrais readonly propriétés - c'est-à-direpropriétés immuables qui ne peuvent pas être modifiées en dehors du constructeur :

public string PropertyName { get; }

public MyClass() { this.PropertyName = "whatever"; }

Au moment de la compilation, cela deviendra :

readonly string pName;
public string PropertyName { get { return this.pName; } }

public MyClass() { this.pName = "whatever"; }

Dans les classes immuables avec beaucoup de membres, cela permet d'économiser beaucoup de code en excès.

Answer 3

Les trois gros inconvénients de l’utilisation de champs au lieu de propriétés sont :

1. Vous ne pouvez pas établir de liaison de données avec un champ alors que vous le pouvez avec une propriété
2. Si vous commencez à utiliser un champ, vous ne pourrez pas ensuite (facilement) le modifier en propriété.
3. Certains attributs que vous pouvez ajouter à une propriété ne peuvent pas être ajoutés à un champ.

Answer 4

Personnellement, j’adore les propriétés automobiles.Quel est le problème avec la sauvegarde des lignes de code ?Si vous souhaitez faire des choses avec des getters ou des setters, il n'y a aucun problème pour les convertir en propriétés normales plus tard.

Comme vous l'avez dit, vous pouvez utiliser des champs, et si vous souhaitez y ajouter une logique plus tard, vous les convertirez en propriétés.Mais cela pourrait poser des problèmes avec toute utilisation de la réflexion (et peut-être ailleurs ?).

Les propriétés vous permettent également de définir différents niveaux d'accès pour le getter et le setter, ce que vous ne pouvez pas faire avec un champ.

Je suppose que c'est la même chose que le mot-clé var.Une question de préférence personnelle.

Answer 5

De Bjarne Stroustrup, créateur du C++ :

Je n'aime pas particulièrement les classes avec beaucoup de fonctions get et set.Cela indique souvent que cela n’aurait pas dû être un cours en premier lieu.C'est juste une structure de données.Et s’il s’agit vraiment d’une structure de données, faites-en une structure de données.

Et tu sais quoi?Il a raison.À quelle fréquence enveloppez-vous simplement des champs privés dans un get et un set, sans rien faire dans le get/set, simplement parce que c'est la chose "orientée objet" à faire.C'est la solution de Microsoft au problème ;ce sont essentiellement des champs publics auxquels vous pouvez vous lier.

Answer 6

Une chose que personne ne semble avoir mentionnée est que les propriétés automatiques ne sont malheureusement pas utiles pour les objets immuables (généralement des structures immuables).Parce que pour cela il faut vraiment faire :

private readonly string title;
public string Title
{
    get { return this.title; }
}

(où le champ est initialisé dans le constructeur via un paramètre passé, puis est en lecture seule.)

Cela présente donc des avantages par rapport à un simple get/private set propriété automobile.

Answer 7

Je crée toujours des propriétés au lieu de champs publics car vous pouvez utiliser des propriétés dans une définition d'interface, vous ne pouvez pas utiliser de champs publics dans une définition d'interface.

Answer 8

Les propriétés automatiques sont autant une magie noire que toute autre chose en C#.Une fois que vous y réfléchissez en termes de compilation en IL plutôt que d'extension en une propriété C # normale, c'est beaucoup moins de magie noire que beaucoup d'autres constructions de langage.

Answer 9

J'utilise les propriétés automatiques tout le temps.Avant C#3, je ne pouvais pas me soucier de toute la saisie et j'utilisais simplement des variables publiques à la place.

La seule chose qui me manque c'est de pouvoir faire ça :

public string Name = "DefaultName";

Vous devez déplacer les valeurs par défaut dans vos constructeurs avec des propriétés.fastidieux :-(

Answer 10

Je pense que toute construction intuitive ET réduisant les lignes de code est un gros plus.

Ce type de fonctionnalités est ce qui rend les langages comme Ruby si puissants (cela et des fonctionnalités dynamiques, qui aident également à réduire l'excès de code).

Ruby a toujours eu cela comme :

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

Answer 11

Le seul problème que j'ai avec eux, c'est qu'ils ne vont pas assez loin.La même version du compilateur qui a ajouté des propriétés automatiques et des méthodes partielles.Pourquoi ils n’ont pas réuni les deux me dépasse.Un simple "On<PropertyName>Changed partiel" aurait rendu ces choses vraiment très utiles.

Answer 12

C'est simple, c'est court et si vous souhaitez créer une véritable implémentation à l'intérieur du corps de la propriété quelque part sur toute la ligne, cela ne cassera pas l'interface externe de votre type.

Aussi simple que cela.

Answer 13

Une chose à noter ici est que, d'après ma compréhension, il s'agit juste sucre syntaxique à l'extrémité C# 3.0, ce qui signifie que l'IL généré par le compilateur est le même.Je suis d’accord pour éviter la magie noire, mais quand même, moins de lignes pour la même chose est généralement une bonne chose.

Answer 14

À mon avis, vous devriez toujours utiliser des propriétés automatiques plutôt que des champs publics.Cela dit, voici un compromis :

Commencez par un interne champ en utilisant la convention de dénomination que vous utiliseriez pour une propriété.Quand tu es pour la première fois

• avoir besoin d'accéder au terrain depuis l'extérieur de son assemblage, ou
• besoin d'attacher une logique à un getter/setter

Faites ceci :

1. renommer le champ
2. rendez-le privé
3. ajouter une propriété publique

Votre code client n’aura pas besoin d’être modifié.

Un jour, cependant, votre système grandira et vous le décomposerez en assemblages séparés et en plusieurs solutions.Lorsque cela se produit, tous les champs exposés reviendront vous hanter car, comme Jeff l'a mentionné, changer un champ public en propriété publique est un changement radical de l'API.

Answer 15

J'utilise CodeRush, c'est plus rapide que les propriétés automatiques.

Pour faire ça:

 private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Nécessite huit frappes au total.

Answer 16

Eh bien, avec des extraits de code, une propriété automatique du même nom représenterait sept frappes au total ;)

Answer 17

@Doménic :Je ne comprends pas..tu ne peux pas faire ça avec les propriétés automatiques ? :

public string Title { get; }

ou

public string Title { get; private set; }

Est-ce à cela que vous faites référence ?

Answer 18

Mon plus gros reproche avec les propriétés automatiques est qu'elles sont conçues pour gagner du temps, mais je constate souvent que je dois les développer plus tard en propriétés complètes.

Ce qui manque à VS2008, c'est un Exploser la propriété automatique refactoriser.

Le fait que nous ayons un encapsuler le champ refactor accélère ma façon de travailler en utilisant uniquement les champs publics.