11
votes

Utilisation de propriétés vs champ de support à l'intérieur de la classe propriétaire

J'aime les propriétés appliquées automatiquement en C # mais dernièrement, cet éléphant se tenait dans ma cabine et je ne sais pas quoi faire avec lui.

Si j'utilise des propriétés appliquées automatiquement (ci-après "AIP"), je n'ai plus de champ de support privé à utiliser en interne. C'est bien parce que l'AIP n'a pas d'effets secondaires. Mais si plus tard, je dois ajouter un traitement supplémentaire dans l'obtention ou la définition?

Maintenant, j'ai besoin de créer un champ de support afin que je puisse développer mes getters et mes configurateurs. C'est bon pour le code externe en utilisant la classe, car ils ne remarqueront pas la différence. Mais maintenant, toutes les références internes à l'AIP vont invoquer ces effets secondaires lorsqu'ils accèdent à la propriété. Maintenant, tous les accès internes à la fois une fois que l'AIP doit être refacturé d'utiliser le champ de support.

Donc, ma question est, qu'est-ce que vous faites la plupart d'entre vous? Utilisez-vous des propriétés appliquées automatiquement ou préférez-vous toujours utiliser un champ de support? Que pensez-vous des propriétés avec des effets secondaires?


2 commentaires

Oui, je me rends compte que les gens ont déjà posé des questions similaires. J'ai utilisé Google, ainsi que sur Stackoverflow, mais je n'ai pas trouvé de réponse définitive / satisfaisante. J'ai donc rependu la question dans mes propres mots.


duplicailler possible de Existe-t-il des raisons d'utiliser des propriétés privées dans C #?


5 Réponses :


6
votes

Eric Lippert a un excellent blog Postez qui répond à cette question:

Si la raison qui a motivé la Changer de mise en œuvre automatiquement propriété pour mettre en œuvre explicitement la propriété devait changer la sémantique de la propriété alors vous devriez Évaluer si la sémantique souhaitée En accédant à la propriété de dans la classe sont identiques à ou différent de la sémantique souhaitée En accédant à la propriété de en dehors de la classe.

Si le résultat de cette enquête est "De l'intérieur de la classe, le souhaité Sémantique d'accéder à cette propriété sont différents de la volonté souhaitée Sémantique d'accéder à la propriété de l'extérieur », alors votre édition a introduit un bug. Vous devriez corriger le bogue. S'ils sont les mêmes, alors votre edit n'a pas introduit un bogue; garder la mise en œuvre identique.


4 commentaires

Pendant que je suis toujours un fan d'un lien El Blog, cette réponse raconte littéralement l'affiche rien. Sa situation hypothétique est que la logique est différente; Ce n'est pas une question qu'il doit se demander.


Je suis respectueusement en désaccord - il s'agit d'une question de sémantique, si vous devez utiliser un champ de support directement sans utiliser de propriété lorsque vous n'avez jamais eu besoin avant, vous enfreignez quelque chose.


Son scénario est qu'il change la sémantique du getter. Il a déjà dit qu'il brise quelque chose, puisqu'il ne veut pas que sa logique interne soit soumise à ce qui a été ajouté à la getter. Sa question était "Que dois-je faire quand c'est le cas?", Et la majeure partie de votre devis consiste à faire cette détermination.


En fait, cela a été long dans ma tête et n'est pas dû à un changement de code spécifique que je fais pour le moment. C'est une recherche de précaution que je commence un nouveau projet et j'essaie de faire les choses "à droite". Depuis C # 3.0, j'ai toujours utilisé des AIPS, mais la plupart de mes collègues ne le font pas. J'ai hérité de beaucoup de code qui pourrait bénéficier d'utiliser des AIPS mais que vous vous êtes demandé s'il y avait peut-être une bonne raison de ne pas le faire. Donc, je suis simplement à la recherche d'opinions.



1
votes

Je ne vois aucun problème à propos de l'utilisation de propriétés appliquées automatiquement. Imaginez que vous ayez une propriété:

private string name;

public string Name 
{
    get { return this.name; }
    set 
    {
       if (!string.IsNullOrEmpty(value))
       { 
           this.name = value;
       }
    }
}


1 commentaires

La question concerne quoi faire (ou comment planifier) ​​lorsque cette modification introduit une logique supplémentaire (indésirable) au sein de la classe, pas comment faire le changement.



0
votes

En termes de séparation des commandes des questions, avoir des propriétés avec des effets secondaires n'est pas vraiment aussi agréable. Je préférerais que mes objets répondent à des questions de la même manière tant que je n'ai pas appelé de méthodes qui indiquent clairement que quelque chose est susceptible de changer.


0 commentaires

0
votes

J'utilise toujours AIP jusqu'à ce que j'ai besoin d'un champ de support. Il n'est pas très difficile de simplement échanger: xxx

pour xxx

Je pense que c'est un gâchis inutile à toujours à ce dernier.


0 commentaires

3
votes

Tout d'abord, Les getteurs de propriété ne doivent pas avoir d'effets secondaires . Ce n'est pas toujours le cas, mais vous devriez avoir une très bonne raison de ne pas l'être.

Cela dit, il est trivial d'obtenir une liste de références à une propriété. Si vous passez à une propriété explicite et que vous souhaitez que votre code privé accède à votre nouvelle variable de support, il devrait s'agir d'une modification assez facile à faire.


5 commentaires

Cela ne s'applique vraiment qu'à l'obtention; côté. L'ensemble; Côté par définition a un effet secondaire.


Ma compréhension des effets secondaires est lorsque le champ de support est modifié à chaque appel à la getter. I.E. Obtenez {_field ++; }. Mais qu'en est-il du moment où vous voulez déclencher un événement comme onpropertychanged ()? Est-ce considéré comme un effet secondaire? Si votre logique interne devait faire trois opérations mathématiques à votre champ de support pour accéder à la valeur finale, vous ne voudriez certainement pas que l'événement de l'état de propriété soit effectué trois fois.


Les effets secondaires peuvent également être utiles: chargement paresseux.


@WhatisPunk: C'est une ligne directrice; Le chargement paresseux est évidemment une exception, mais l'utilisateur doit être conscient que l'obtention de la propriété pourrait potentiellement une opération coûteuse, car les propriétés sont / étaient destinées à être très légères, les opérations de poids lourds sont déplacées vers des méthodes. Qui étant dit, IMHO Obtenir la valeur d'une propriété ne devrait pas soulever un événement sur le même objet, ni l'incidence (idéalement) affecter la valeur d'une autre propriété, car il ne devrait y avoir aucune logique derrière le commande dans laquelle les propriétés sont accessibles ou définies.


Tu as raison. Je ne pensais pas vraiment ça. Le getter n'appellerait jamais surpropertychangned.