Meilleure pratique d'utilisation locale de la propriété privée x

StackOverflow https://stackoverflow.com/questions/833047

Question

Lorsque vous êtes dans une classe et que vous avez un domaine privé et que vous exposez ce champ dans une propriété publique, lequel dois-je utiliser depuis la classe?

Ci-dessous, vous trouverez un exemple de ce que je suis en train de découvrir. Faut-il manipuler le champ privé _Counter ou le compteur de propriétés?

Test de classe publique 

Private _Counter As Integer

Public Property Counter() As Integer
    Get
        Return _Counter
    End Get
    Set(ByVal value As Integer)
        _Counter = value
    End Set
End Property

Private Sub Dosomething()

    'What is the best practice?
    'Direct access to private field or property?

    'On SET
    _Counter += 1
    'OR
    Me.Counter += 1

    'On Get
    Console.WriteLine(_Counter)
    Console.WriteLine(Me.Counter)

End Sub

Classe de fin

Merci d'avance pour l'aide. Edu

Était-ce utile?

La solution

À mon avis, l’utilisation d’un accesseur public en interne est une surencapsulation: elle brouille le code. Avec une telle approche, des opérations simples appellent des accesseurs pouvant contenir une logique plus complexe. Il est donc plus difficile d'analyser le code des opérations.

Dans mon expérience en programmation, j'ai rarement eu une situation où cela aiderait beaucoup. Au lieu de cela, je préfère accéder aux champs directement, et uniquement si cela est vraiment nécessaire, pour résumer l'accès en créant un accesseur privé , qui peut être utilisé à la fois par l'accesseur public et par d'autres fonctions. La raison en est que si vous devez associer une logique spéciale à l’accesseur public, il est probable que la logique ne soit pas la même pour l’accès interne.

Notez également que la plupart des IDE modernes (comme Eclipse) permettent de voir immédiatement toutes les références à un champ privé et de refactoriser le code pour utiliser une fonction au lieu d'un accès direct.

Autres conseils

IMO, vous devez utiliser Accesseur de propriété autant que possible. En effet, vous n'avez pas à vous soucier de la logique interne qui pourrait être disponible lorsque vous avez une propriété.

Un bon exemple de cela se trouve dans le code situé derrière un Linq DataContext.

regardez ceci ... 

[Column(Storage="_ReviewType", DbType="TinyInt NOT NULL")]
public byte ReviewType
{
    get
    {
        return this._ReviewType;
    }
    set
    {
        if ((this._ReviewType != value))
        {
            this.OnReviewTypeChanging(value);
            this.SendPropertyChanging();
            this._ReviewType = value;
            this.SendPropertyChanged("ReviewType");
            this.OnReviewTypeChanged();
        }
    }
}

Remarquez toute cette logique dans le "setter"?

C'est pourquoi il est important de commencer à appeler vos propriétés au lieu de champs, IMO.

Merci à tous pour vos réponses et vos suggestions.

Après avoir pris en compte toutes les suggestions présentées ici ainsi que d’autres recherches, j’ai l’impression que, pour cette situation entre Private Field et Assessor, il s’agit plus d’un choix personnel. Donc, fondamentalement, le plus important est que peu importe ce que vous choisissez, soyez cohérent.

Cela dit; ma règle personnelle penche vers ceci:

  1. Accédez directement à vos champs privés.

  2. Si vous accédez aux accesseurs, utilisez le mot-clé ME. pour améliorer la lisibilité

  3. Utilisez l'accesseur uniquement s'il implémente une logique logique essentielle qui s'applique également à l'accès privé. De cette façon, vous savez que si vous utilisez l'accesseur, c'est parce qu'il y a quelque chose d'autre.

  4. Évitez d’utiliser des champs protégés. Les classes dérivées doivent toujours utiliser l'accesseur, jamais accéder directement au champ.

Faites-moi savoir ce que vous pensez.

Note:

Après cela, je pense qu'il nous manque une nouvelle portée pour les champs de niveau classe. Un mot clé tel que & # 8220; Restricted & # 8221; où ce champ est accessible uniquement à partir de son getter / setter. De cette façon, vous accédez toujours directement aux champs privés, mais si vous devez vous assurer que certains accesseurs ne peuvent y accéder que par leur accesseur, modifiez les champs Privé en Restricté. (Que diriez-vous de "Restricted, RestrictedRead et RestrictedWrite"?)

Je préfère utiliser la propriété chaque fois que possible. Cela vous donne la possibilité à l'avenir de modifier ce que la propriété retourne / définit sans avoir à parcourir et à rechercher tous les emplacements qui utilisaient la variable privée.

Utilisez le champ privé car vous ne faites pas quelque chose de spécifique dans le setter.

Je recommanderais également de supprimer le configurateur de propriétés, afin de forcer l'état du compteur à être défini par la méthode donnée DoSomething ()

En fonction de la situation, il peut être préférable d'autoriser la modification directe d'un champ sur une classe uniquement, et / ou via une méthode associant la sémantique à la modification. De cette façon, il devient plus facile de raisonner sur cette classe et cette valeur particulière, puisque vous pouvez être certain qu’elle ne sera modifiée que d’une certaine manière. De plus, à un moment donné, une action telle que incrémenter et int peut avoir des conséquences supplémentaires requises, à quel point il est plus logique d'exposer l'accès à cette ressource par le biais de méthodes.

Je utilise toujours les accesseurs de propriété, car je suis sûr de pouvoir éventuellement ajouter de la logique dans le getter ou le setter, sachant à coup sûr qu'aucun code ne l'ignore.

Si vous êtes inquiet à propos des frais généraux liés à l'appel des accesseurs de propriétés lorsqu'ils se rendent directement sur le terrain, ne le faites pas. La plupart des compilateurs intègrent ce genre de choses, vous donnant effectivement les mêmes performances. Au moins, il est peu probable que vous ayez besoin des nanosecondes supplémentaires que vous pourriez gagner en allant directement sur le terrain.

Il est préférable de rester avec les accesseurs de propriétés, car a) vous pouvez être très cohérent dans tout votre code, ce qui le rend plus facile à maintenir et b) vous bénéficiez des avantages mentionnés par d'autres ici.

De plus, je n'ajoute généralement pas les mots clés Me. (ou this. ), sauf en cas de problème de portée (que j'essaie d'éviter en choisissant mes identificateurs. soigneusement). Cela ne me laisse pas perplexe car mes fonctions et mes sous-programmes ne sont jamais aussi longs que je ne suis pas sûr de travailler avec une variable locale (basée sur une pile) ou un membre de la classe. Quand ils sont trop longs à dire facilement, je refactorise.

L’affiche originale est EXACTEMENT correcte.

1) Accédez directement à vos champs privés.

  • Facilite la refactorisation.

2) Si vous accédez aux accesseurs, utilisez le mot-clé ME. pour améliorer la lisibilité

  • explicitement lister la portée nécessite moins de réflexion de la part du lecteur

3) Utilisez l'accesseur uniquement s'il implémente une logique logique essentielle qui s'applique également à l'accès privé. Ainsi, vous savez que si vous utilisez l'accesseur, c'est qu'il y a & # 8220; quelque chose d'autre à cela & # 8221;

  • c'est la seule raison pour enfreindre la règle 1.

4) Évitez d’utiliser des champs protégés. Les classes dérivées doivent toujours utiliser l'accesseur, jamais accéder directement au champ.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top