En C#, utiliser des Propriétés ou des Attributs et pourquoi ?

Je ne suis pas sûr de moi, je ne sais plus au fait pourquoi je déclare les propriétés publiques d'un objet à la façon snypet "propfull" alors que je pourrais utiliser un champ. Je cherche la réponse la plus pertinente et ce matin je tombe sur l'article suivant :

Développez.com .NET C# Propriété ou attribut ? Pourquoi ?

Développez.com .NET C# Propriété ou attribut ? Pourquoi ?

Je me dis alors que cela vaut le coup que je le lise ... Mais il est bien long alors résumons. Il s'agit donc bien de comparer les deux écritures de codes suivantes :

class Test
{
    public int MonChamp;
}

Et :

class Test
{
    private int _monAttributPrivé;

    public int MaPropriété
    {
        get
        {
            return _monAttributPrivé;
        }
        set
        {
            _monAttributPrivé = value;
        }
    }
}

Quelles sont les différences ? Bon, je me tape tout l'article et croyez moi ce n'est pas une sinécure. Pour finalement me dire que la deuxième écriture prépare mieux mon composant à de futures évolutions comme par exemple :

private int myProperty;
public int MyProperty {
     get { return this.myProperty; }
     set { this.myProperty = value < 0 ? 0 : value; }
}

Mais encore ? On nous dit qu'en cas d’utilisation de la sérialisation XML seules les propriétés des classes sont considérées les champs ne le sont pas.

Lors de la transformation d'un champ en propriétés les assemblys dépendantes seront affectés si elles n'ont pas été recompilées et affectera évidemment tout procédé utilisant la réflexion.

Pourquoi les propriétés plutôt que les champs ?

Heureusement, tout en bas "Guulh" qui devait être un peu énervé de voir cette discussion s'éterniser sans réelle bonne réponse fini par écrire :

Donc, pourquoi les propriétés plutôt que les champs ?

Ca m'épate qu'on puisse vouloir se passer volontairement des propriétés automatiques... Si on commence à dire qu'on veut garder des champs privés "parce que ça peut servir", alors autant remettre le constructeur par défaut "parce que ça peut servir", autant implémenter IDIsposable "parce que ça peut servir", autant définir explicitement add/remove sur les event pour la même raison. 

Parce qu'on ne peut pas définir de champ dans une interface

Parce qu'on ne peut pas rendre un champ virtuel

Parce que plein d'API faisant appel à la réflexion (sérialisation, binding, ...) ne gère que les properies et pas les champs

Parce que c'est un breaking change et donc une lib_B qui référence A ne marchera plus sans être recompilée si un champ de A devient une propriété

Parce que d'un point de vue perf, on s'en fout, c'est le jitter qui se chargera d'inlier tout ça

Parce que ça montre bien qu'une classe, en tant qu'unité d'encapsulation, ne donne jamais accès à son état interne sans se laisser la possibilité de valider/notifier/whatever

Parce que ça normalise ce qu'expose une classe/une interface: des propriétés, des méthodes, des events, et c'est tout.

Parce que c'est le standard, et que si chacun fait à sa sauce pour ce genre de choix consensuel, ça engendre un surcoût projet inutile en temps d'adaptation, de refactoring, etc ...

Pourquoi les propriétés automatiques plutôt que les propriétés manuelles (dans le cas of course où on fait rien dans le get set)

Moins verbeux!

pas de problématique de convention de nommage (je mets un underscore? une minuscule? du hongrois?

parce que l'intellisense n'est pas pollué à l'intérieur de la classe par deux fois plus de tokens que nécessaire

Bravo Guulh !

Conclusion

Il s'agit bien de prévoir l'évolution de notre Classe composant, c'est une bonne raison pour utiliser des propriétés plutôt que des champs.

Ne trouvez-vous pas ?

Merci de me laissez votre commentaire.