En savoir plus sur les propriétés implémentées automatiquement

Question

J'ai la classe simple à l'aide de solutions auto-implémentées:

Public Class foo
{
    public foo() { }  

    public string BarName {get; set;}
}

J'utilise évidemment la variable BarName dans toute ma classe et je dois maintenant ajouter une logique lorsque la valeur de la propriété est définie (il doit être entièrement en majuscule, comme indiqué). Est-ce que cela signifie que je dois maintenant créer une variable privée pour BarName, par exemple. _BarName et remplacez la variable BarName actuelle utilisée dans toute la classe par _BarName?

Public Class foo
{
    public foo() {}  

    private string _BarName = "";
    public string BarName 
    { 
        get {return _BarName;}
        set {_BarName = Value.ToString().ToUpper();}
    }
}

J'essaie de bien comprendre les implications de l'utilisation de propriétés implémentées automatiquement et de ce que cela impliquera ultérieurement si / si je dois changer quelque chose. Je suppose que le refactoring, comme indiqué ci-dessus, n'est pas un briser changer parce que la propriété reste fondamentalement la même; il a simplement fallu un peu de travail à l'intérieur de la classe pour que cela reste ainsi et pour ajouter la logique nécessaire.

Un autre exemple, qui peut être plus significatif, est que je dois appeler une méthode lorsqu'un setter ou un getter est utilisé; plus que changer la valeur.

Cela semble être un commerce équitable entre les lignes et les lignes de code pour configurer les propriétés.

Answer 1

  

Est-ce que cela signifie que je dois maintenant   créer une variable privée pour BarName

Oui

  

et changer le nom de barre actuel   variable utilisée tout au long de ma classe

Ne modifiez pas le reste du code de votre classe pour utiliser la nouvelle variable privée que vous créez. BarName , en tant que propriété, est destiné à masquer la variable privée (entre autres), afin d'éviter les modifications radicales que vous envisagez d'apporter au reste de votre code.

  

Je suppose que la refactorisation, comme   ci-dessus, n'est pas un changement radical   parce que la propriété est fondamentalement   rester le même; il a juste fallu un   peu de travail pour le garder de cette façon et   ajoutez la logique nécessaire.

Corrigez.

Answer 2

Vous n'avez rien à changer. Les propriétés implémentées automatiquement ne sont que du sucre syntaxique. Le compilateur génère la variable privée et la logique get / set pour vous, dans les coulisses. Si vous ajoutez votre propre logique getter / setter, le compilateur utilisera votre code au lieu de son code généré automatiquement, mais en ce qui concerne les utilisateurs de cette propriété, rien n'a changé. tout code référençant votre propriété continuera à fonctionner.

Answer 3

Lors de l'utilisation de propriétés automatiques, vous ne bénéficiez pas d'un accès direct au "support" sous-jacent. variable et vous n’avez pas accès à la logique qui est implémentée dans la propriété getter et setter. Vous avez uniquement accès à la propriété (utilisez donc BarName dans tout votre code).

Si vous devez maintenant implémenter une logique spécifique dans le configurateur, vous ne pouvez plus utiliser les propriétés automatiques et vous devez implémenter la propriété dans le paramètre "old fashioned". façon. Dans ce cas, vous devez implémenter votre propre variable de sauvegarde privée (la méthode préférée, du moins pour moi, consiste à nommer la variable de sauvegarde privée le même nom que la propriété, mais avec une minuscule initiale (dans ce cas, la valeur de sauvegarde). la variable s'appellerait barName). Vous mettriez alors en œuvre la logique appropriée dans le getter / setter.

Dans votre exemple, vous avez raison de dire qu'il ne s'agit pas d'un changement radical. Ce type de refactoring (passage de propriétés automatiques à des propriétés "normales") ne devrait jamais être un changement radical, car vous ne modifiez pas l'interface publique (le nom ou l'accessibilité de la propriété publique).

Answer 4

N'utilisez pas les propriétés automatiques si vous savez que vous allez valider cet objet. Ces objets peuvent être des objets de domaine, etc. Comme si vous aviez une classe Client, utilisez des variables privées, car vous devrez peut-être valider le nom, la date de naissance, etc. Mais si vous utilisez une classe Rss, vous pourrez simplement utiliser les propriétés automatiques. étant donné qu'aucune validation n'est en cours d'exécution et que la classe est simplement utilisée pour stocker certaines données.

Answer 5

Vous avez raison en ce qui concerne le refactoring et il ne devrait vraiment rien casser.

Que vous deviez ou non consulter les références de la classe pour en modifier le nom de la propriété et les modifier pour faire référence au champ privé dépendrait de la question de savoir si le code interne devait accéder à la représentation sous-jacente des données plutôt que de la façon dont il était utilisé. a été présenté aux consommateurs de la classe. Dans la plupart des cas, vous pourriez vous en sortir suffisamment.

Dans votre exemple simple, il serait sage de laisser suffisamment de soin et de s’assurer qu’aucun code interne à la classe ne puisse altérer la conversion / mise en forme en cours d’exécution dans le configurateur.

Si, en revanche, le getter faisait quelque chose de magique pour changer la représentation interne du champ en fonction de la manière dont les consommateurs devaient visualiser les données, il serait peut-être nécessaire (dans certains cas) que le code interne de la classe accède au champ .

Vous devez examiner chaque occurrence de l'accès à la propriété automatique dans la classe et décider si elle doit toucher le champ ou utiliser la propriété.

Answer 6

Les propriétés automatiques ne sont que du sucre syntaxique. Le compilateur en crée le membre privé, mais comme il est généré au moment de la compilation, vous ne pouvez pas y accéder.

Et plus tard, si vous souhaitez implémenter des getters et des setters pour la propriété, vous créez un membre privé explicite pour cette propriété et ajoutez la logique.