J'ai des cours qui ont des propriétés automatiques uniquement comme le nom de Customernie publique {Obtenir; ensemble;}. Ils sont publics parce qu'ils sont accessibles en dehors de la classe. Ils peuvent également être accessibles à l'intérieur de la classe. Ils offrent une bonne encapsulation et un meilleur débogage. Je peux mettre un point d'arrêt sur un si j'ai besoin de savoir qui l'accède et quand.
Ma question est de savoir quels sont les inconvénients de l'utilisation de propriétés uniquement sans champs correspondants? Je peux faire le setter ou getter privé, interne .. etc., ce qui signifie que j'ai aussi une flexibilité de la scope si nécessaire.
8 Réponses :
Il n'y a pas d'inconvénients pour des propriétés simples. Le compilateur crée le champ de support pour vous. Ce Blog Entrée explique comment le compilateur traite automatiquement les propriétés.
La chose est, là est un champ correspondant. Vous ne le voyez tout simplement pas parce que le compilateur le crée pour vous. Les propriétés automatiques ne sont que du sucre syntaxique ou du sténographie de créer le champ.
Vous ne pouvez pas créer Sinon, comme indiqué ci-dessus, il n'y a pas d'autres inconvénients.
Je n'aijoute que ce commentaire car ce n'est plus vrai. Public int x => 3 est traité comme une propriété sans SET accessor, même à l'intérieur de l'objet contenant.
Pas de choses majeures. Juste des cas de bord comme où vous devez passer une propriété sur une méthode où le paramètre est passé par référence ( EDIT: OH, et appuyer sur les propriétés "NO ref ou out ) qui n'est pas possible avec une propriété (car En interne, ils ne sont que des méthodes Get_Property / Set_Property mis en œuvre par le compilateur, pas des champs spéciaux de quelque nature que ce soit) et vous auriez besoin d'un champ de support privé explicite pour cela.
READONLY ", qui est en fait assez courant.
Si vous n'avez pas besoin d'effectuer une logique spécifique dans les accessoires Get and / ou Set, il n'y a pas d'inconvénient ...
Je dis qu'ils sont mauvais d'un point de vue de la lisibilité du code. Syntaxe Sugar est agréable pour écrire du code mais horrible pour le code de lecture. En tant que développeurs, le code que nous laissons derrière nous sera finalement hérité de certains développeurs pauvres qui devront donner un sens à ce que nous avons fait et ce qui se passe dans le code. Je suis vraiment contre la modification d'une langue pour enregistrer simplement des frappes de frappe lorsqu'il existe une syntaxe établie pour les mêmes constructions.
Je ne dirais pas que cela le rend moins lisible. Vous avez un champ de moins à lire, et le code dit: «C'est une propriété la plus simple possible, il est ici simplement pour permettre l'encapsulation si j'en ai besoin un jour».
Pourquoi est-ce moins lisible? Vous parlez-vous à la partie de la propriété automatique du fait qu'il n'y a pas de champ défini? De toute façon, tout bon développeur ce que la propriété est utilisée?
Pas vraiment un inconvénient, mais vous devez être conscient des valeurs par défaut des propriétés automatiques. Avec des propriétés "classiques", nous avons toujours l'habitude d'initialiser les champs de support, par ex. comme ceci: Cela a fait évident que la valeur par défaut de la propriété est. avec des propriétés automatiques, vous devez savoir quelles sont les valeurs par défaut pour les différentes types (par exemple faux pour Bool). Si vous ne voulez pas que la propriété ait la valeur par défaut, vous devez l'initialiser dans le constructeur: ceci signifie que vous mais comme je l'ai écrit, je ne pense pas vraiment cela comme un inconvénient, juste quelque chose que vous devez savoir.
sérialisation avec C'est une bonne raison de regarder plutôt un sérialisateur basé sur un contrat. Voir Cette entrée de blog pour plus d'informations. Binarinformatter - Vous avez des problèmes Binarinformatter utilise les noms de champs. Et vous ne pouvez pas dupliquer cela, car le nom du champ génère le compilateur ne peut pas être écrit comme légal C #.
C'est méchant, et pas quelque chose à considérer du tout mais - pourriez-vous vous pirater en cochant le nom de champ automatique dans le réflecteur?
Cela n'en aidera pas beaucoup - le nom de champ ne peut pas être écrit en C # (intentionnellement) - vous devez donc mettre en œuvre iserialisable ou une série de substitution de sérialisation; Beaucoup de travail simplement parce que vous vouliez ajouter une validation à une propriété. Mais pour souligner: ma réponse ici est "N'utilisez pas Binaryformatter" - et continuez à utiliser des auto-accessoires ;-p
+1 Tout ce qui révèle un cas de bord ou des problèmes spécifiques avec quelque chose me pose une bonne question. (Re: La complication BinaryFormatter de Marc)