C # champ de protection privé, ajouter des biens - pourquoi?

Question

Dans Visual Studio 2008 Team System, j'ai couru l'analyse du code (dans le menu Analyser) sur un de mes projets C #. L'un des avertissements produits est la suivante:

  

Microsoft.Design. Parce que le champ « Connection._domain » est visible à l'extérieur de son type déclarant, modifier son accessibilité au secteur privé et ajouter une propriété, avec la même accessibilité que le domaine a actuellement, pour fournir l'accès

Il fait référence au champ suivant:

public abstract class Connection
{
    protected string _domain;
}

Je ne comprends pas le raisonnement derrière la suggestion. Voilà ce que je pense qu'il veut que je fasse:

public abstract class Connection
{
    private string _domain;
    protected string Domain { get { return _domain; } set { _domain = value; } }
}

Deux questions:

1. Ai-je bien compris ce que la suggestion veut que je fasse, sage-code?
2. Pourquoi veut-il que je fasse cela?

Answer 1

Oui, je pense que vous avez bien compris - bien que dans les versions ultérieures de C #, il y a une façon plus concise de l'écrire:

public string Domain { get; set; }

Pourquoi? Il est tout au sujet de l'encapsulation. Si vous le faites comme il l'indique, vous pouvez ensuite modifier la définition de la propriété de domaine sans affecter un code d'appel qui utilise cette propriété. Étant donné que votre classe est public, et pourrait éventuellement être appelé par le code que vous n'avez pas écrit, c'est potentiellement très important.

Answer 2

Yep. C'est la suggestion. Vous ne devriez pas avoir accès plus élevé que privé exposée champs d'instance directe.

Il est l'un des principes de OOD -. Encapsulation aussi appelé « données cachées »

Answer 3

1. Oui, vous avez fait correctement le code de problème sage.
2. Il est sur l'encapsulation. _domain est des données sur votre objet. Plutôt que de l'exposer directement afin que tout client dispose d'un accès non filtré, vous devez fournir une interface pour eux d'y accéder. En pratique, cela pourrait être d'ajouter la validation du compositeur afin qu'il ne peut pas être réglé sur une valeur. Il peut sembler idiot si vous êtes le seul code d'écriture parce que vous savez comment fonctionne votre API. Mais essayer de penser à des choses sur un grand niveau de l'entreprise, il est préférable d'avoir une API afin que votre objet peut être considéré comme une boîte qui accomiplishes une tâche. Vous pourriez dire que vous aurez jamais le besoin d'ajouter quelque chose comme la validation à cet objet, mais les choses sont faites de cette façon de tenir la possibilité, et aussi d'être cohérent.

Answer 4

Votre traduction est correcte. Le même argument pour peut être fait pour utiliser les propriétés « protégées » que peut être fait pour utiliser les propriétés « publiques » au lieu d'exposer les variables membres directement.

Si cela conduit simplement à une prolifération des accesseurs simples et setters alors je pense que les dommages au code readablity l'emporte sur l'avantage de pouvoir changer le code dans l'avenir. Avec le développement de propriétés générées par le compilateur C # ce n'est pas tout à fait si mal, il suffit d'utiliser:

protected string Domain { get; set; }

Answer 5

En effet, si vous avez toujours voulu changer le champ à une propriété à l'avenir vous briser toutes les autres assemblées qui en dépendent.

Il est bon de garder tous les domaines privé et les envelopper dans des propriétés afin que vous avez la possibilité d'ajouter une validation ou une autre logique à l'avenir sans recompiler tous les consommateurs (ou dans ce héritières cas) de votre classe.

Answer 6

En réponse à votre question ... oui.

Cependant, je voudrais simplement utiliser la syntaxe auto-propriété:

public abstract class Connection
{
    protected string Domain { get; set; }
}

Answer 7

En fait, les propriétés fournissent plus de retour ou la fixation d'un membre. Ils vous permettent d'ajouter une logique qui pourrait vérifier un format d'entrée approprié, la validation de la plage, etc.

La réponse sélectionnée à partir du lien met le mieux, « Propriétés encapsuler. Vous pouvez encapulate toute validation nécessaire / formattage / conversion dans le code de la propriété. Ce serait difficile à faire pour les champs. »

http: / /social.msdn.microsoft.com/Forums/en-IE/netfxbcl/thread/985f4887-92ae-4ec2-b7ae-ec8cc6eb3a42

Answer 8

En plus des autres réponses mentionnées ici, les membres du public / protégés qui commencent par un trait de soulignement ne sont pas CLS conforme dans la mesure où il n'y a pas besoin de langages .NET pour soutenir les membres avec les traits de soulignement, de sorte que quelqu'un héritant de votre classe dans une autre langue .NET peut ne pas être en mesure d'accéder à ce particulier membre protégé.

Je sais, il ne s'applique probablement pas pour vous, mais il pourrait faire partie de la raison de l'avertissement d'analyse de code.