Les classes privées doivent-elles être accessibles par propriétés?

Question

J'utilise une instance d'une classe privée en tant qu'objet d'état fourni à une opération stream.BeginRead. (La classe est privé à ma classe principale de lecture/écriture de flux.)

public class MainClass 
{ 
    // ... 

    private class ResponseState 
    { 
     public IResponse response; 
     public Stream stream; 
     public byte[] buffer = new byte[1024]; 
    } 
} 

L'accès à la classe est via les champs directement. Dois-je vraiment fournir l'accès à la classe via des propriétés dans ce cas, même si elle doit seulement être utilisée pour l'état de conservation?

Intéressé de savoir ce que les autres font.

Answer 1

je - encapsulation est utile à l'intérieur de la classe, ainsi qu'à l'extérieur de la classe. En canalisant tous les accès à un membre via une interface bien connue (c'est-à-dire la propriété), vous vous donnez la possibilité d'ajouter ultérieurement de la logique autour de cet accès sans modifier le code appelant. Cela peut sembler exagéré, mais honnêtement, compte tenu des propriétés implémentées automatiquement, il est si facile de déclarer une propriété que vous pouvez aussi aller de l'avant et en utiliser un pour vous donner une flexibilité maximale.

Answer 2

Il n'est pas nécessaire par le langage C#, mais il est une bonne pratique de ne jamais exposer directement un champ pour des raisons de maintenabilité - il est suggéré d'utiliser une propriété à la place.

Voir StyleCop SA1401: FieldsMustBePrivate.

TypeName - FieldsMustBePrivate
CheckId - SA1401
Catégorie - maintenabilité Règles

cause

Un champ dans une classe C# a un modificateur d'accès autre que privé.

Description de la règle

Une violation de cette règle se produit chaque fois qu'un champ dans une classe a accès non-privé. Pour des raisons de maintenabilité, les propriétés doivent toujours être utilisées comme mécanisme d'exposition des champs en dehors d'une classe, et les champs doivent toujours être déclarés avec un accès privé. Cela permet à l'implémentation interne de la propriété de changer au fil du temps sans modifier l'interface de la classe.

Les champs situés dans C# struct sont autorisés à avoir un niveau d'accès.

Comment corriger les violations

Pour corriger une violation de cette règle, faites privée et ajoutez le champ une propriété pour exposer le champ à l'extérieur de la classe.

Si votre classe est purement un état pour la classe conteneur, vous pouvez envisager de placer les membres directement dans la classe qui les utilise. Si votre classe est plus que juste un état (et je le soupçonne), alors il devrait suivre les règles habituelles de maintenabilité.

Answer 3

Dans mon organisation, lorsqu'une classe était privée ou interne, et il est une classe d'entité, nous avons utilisé les champs publics pour y accéder.

Cependant, depuis C# 3.0 nous utilisons automatic properties, donc nous utilisons toujours des propriétés pour accéder aux champs privés.

Quoi qu'il en soit, l'effet est le même, dans notre cas c'était de rendre le code plus lisible.

Answer 4

La meilleure pratique consiste à utiliser des propriétés pour chaque membre accessible par d'autres types. Les propriétés automatiques de C# 3.0 rendent cela assez facile.

Answer 5

Je viens de faire quelques lectures à ce sujet il y a une semaine ou deux. Il y a les deux camps. La majorité dit que vous devez envelopper dans la propriété parce que mon professeur l'a dit et que tout le monde le fait. Ils disent qu'il est plus facile d'ajouter une logique supplémentaire à une propriété ou plus maintenable et d'autres raisons faibles. L'autre camp, s'appellent eux-mêmes "les vrais gars OO" ont tendance à être sur la ligne de si vous utilisez les propriétés du tout vous le faites mal (à quelques exceptions près bien sûr). Votre cas serait l'exception pour autant que je sache. En fait, en y réfléchissant, ils diraient probablement que vous vous trompez :) Je ne peux pas gagner. Quoi qu'il en soit, ils disent aussi que si vous allez les utiliser, ne dérangez pas à moins d'avoir besoin de la logique supplémentaire de vos setters et getters. Pourquoi ralentir votre programme pour rien. (apparemment, ils peuvent mesurer la lenteur aussi).

J'ai tendance à utiliser des propriétés sur des champs car je fais beaucoup de MVVM et j'ai besoin d'implémenter INotifyPropertyChanged qui en a besoin. Dans votre cas, je ne m'inquiéterais pas de les emballer dans des propriétés juste pour la graisse inutile. Mais si c'était dans une classe qui avait besoin d'une propriété alors je les emballerais pour garder des choses similaires dans cette classe. Si après tout ce que vous n'avez pas enveloppé, et nécessaire pour plus tard, c'est un clic droit refactor-> encapsuler le champ pour envelopper une propriété si vous avez Resharper.