Dans une discussion avec un pair, il a été élevé que nous devions envisager d'utiliser des propriétés automatiques pour toutes les variables de niveau de classe ... y compris des privées.
Ainsi, en plus d'une propriété publique comme si: P>
private int _myProperty2;
6 Réponses :
Les propriétés automatiques privées sont totalement inutiles, à mon avis. Quelle valeur une propriété auto privée fournit-elle qu'un champ uni ne signifie pas?
(C'est différent lorsque l'auto-propriété n'est que partiellement privée - par exemple, un getter public / protégé avec un séchoir privé - ou lorsque vous utilisez une propriété privée non automatique pour vous permettre Pour envelopper un code supplémentaire autour du getter / Setter.)
Ce n'est pas aussi utile pour les privés que pour les publics.
Supposons que vous ayez pris votre propriété privée automatique et avons ensuite construit une certaine logique (pouvant le faire sans ne rien briser, c'est tout le point de l'accessoire automobile) ...
Cela vous obligerait à créer un membre de support privé pour que la propriété enveloppe.
Alors maintenant, vous avez deux manières privées différentes (membre et propriété) de faire la même chose bien que l'on a des effets secondaires cachés (la propriété) et vous avez maintenant le problème de ne pas vous assurer aucune de vos autres méthodes de l'accès de la classe à ce membre directement.
finit par être beaucoup plus en tête de tête que d'utiliser un membre privé depuis le début.
Si je pouvais accepter plus d'une réponse, j'accepterais celui-ci aussi. Je pense que les deux réponses en conjonction offrent un bon raisonnement pour éviter ce comportement.
C'est pourquoi la préfixation des membres de la sauvegarde privée est utile. Traditionnellement, j'utilise le _, car cela empêchera Intellisense de saisir le membre privé lors de la rédaction de code, mais c'est une mauvaise pratique en C ++. Je envisage donc un préfixe différent, comme "P_" pour les magasins de support privés qui ne doivent pas être consultés directement. Ce que j'aimerais vraiment voir, c'est une périmètre locale pour les champs de support, une sorte de «valeur» est implicitement déclarée. Peut-être "thisp".
Qu'est-ce que cette stratégie fera pour vous, c'est la possibilité de mettre des changements futurs dans la propriété privée auparavant autogogéné sans affecter aucun des autres code qui obtient ou définit votre propriété privée. Personnellement, je n'ai pas beaucoup utilisé cela mais cela peut être bénéfique dans un cas où des modifications apportées à la manipulation peuvent survenir. Il standardise également le code afin que les champs soient toujours accessibles par des propriétés. Il n'y a pas d'inconvénients réels, mais ce n'est pas vraiment avantageux dans la plupart des situations non plus. Je pense que le style est vraiment le plus gros pilote de la plupart des situations.
a du sens pour les propriétés publiques mais pas pour privé - voir ma réponse
Je vois une exécution de code plus lente et des exécutables plus grands comme une raison suffisante pour ne pas faire quelque chose comme ça. L'ajout de déclarations de propriété inutiles peut signifier que le programme génère du code supplémentaire pour accéder à ces variables des membres. Mais alors, je viens de l'ère 8 bits où chaque octet comptait.
Cela ne fait pas trop de sens.
Je peux penser à un "avantage":
Mais franchement, vos cours ne devraient pas devenir si gros que cela soit utile.
"Y a-t-il des problèmes"?
Vos propriétés ne fonctionneront pas comme des arguments sur
REF ouOUT Paramètres.
mais plus tard, l'ajout de logique nécessite de créer un membre privé pour soutenir la propriété ... et vous ne pouvez pas garantir réellement que d'autres codes ne pourront pas accéder directement à ce membre directement.
@ROBERT: True mais au point d'ajouter la logique, vous savez qu'il sera utilisé correctement par le code existant. C'est tout.
Au moins dans VS 2015, vous obtenez également un compte de référence aux variables automatiques.
Dans une discussion avec un pair, c'était élevé que nous devrions considérer Utilisation des propriétés Auto pour toutes les catégories variables de niveau ... y compris privées ceux.
- Cela ne sera pas utile, au cas où vous n'avez pas de logique pour écrire dans vos propriétés pour récupérer et retourner des valeurs.
- Outre le point 1, vous avez la seule propriété Donc, vous pouvez aller directement avec
public int myProperty1 {obtenir; ensemble; }En outre, il réduit votre ligne de code et votre implémentation rapide
Je suis un croyant ferme en baiser. Je n'utilise jamais de propriété quand un champ fera, et je vois très peu de raisons d'utiliser des accesseurs privés (obtenir).
L'objectif principal d'une propriété est d'être un accesseur public de données privées. Donc, pour des propriétés simples qui ne font que définir ou obtenir une valeur, des accesseurs privés et des setters n'ont aucun sens.
Cela dit, lorsque vous devez transformer les données en cours de lecture, ou lorsque vous devez effectuer un effet secondaire lors de la mise à jour de la valeur, vous devez utiliser un champ. Changer votre valeur augmente-t-elle un événement? Ensuite, un champ est un avertisseur. Mais alors, ce n'est pas un domaine automatique que vous déclarez avec {obtenir; ensemble;}
D'un point de vue de design, il est préférable de garder ce que vous avez, cela aide à distinguer ce qui est privé et ce qui est public simplement en regardant le code.
Dupliqué possible de Quels sont les avantages de l'utilisation de propriétés en interne?