À quelle fréquence vous voyez abus de getters / setters sténographiques C #?

Question

En C #, vous pouvez créer getter / setters d'une manière plus simple que d'autres langues:

public int FooBar { get; set; }

Cela crée une variable interne privée que vous ne pouvez pas répondre directement, avec la propriété extérieure « foobar » pour y accéder directement.

Ma question est - comment voyez-vous souvent cette victime de violence? Il semble que il a un fort potentiel de violer l'encapsulation des meilleures pratiques souvent. Ne vous méprenez pas, je l'utilise, selon le cas, et les variations partielles de celui-ci pour en lecture seule écriture seule types de propriétés, mais quelles sont vos expériences désagréables avec des autres auteurs dans votre base de code?

Précision:. La définition prévue de la violence serait en effet de créer une telle propriété lorsque les variables privées sont appropriées

Answer 1

Je l'ai vu abusé (à mon avis). En particulier, lorsque le développeur normalement écriture:

private readonly int foo;
public int Foo
{ 
    get 
    { 
        return foo;
    }
}

ils écrivent parfois:

public int Foo { get; private set; }

Oui, il est plus court. Oui, à partir de l'extérieur de la classe, il a la même apparence - mais je ne considère pas ces derniers comme la même chose, que cette dernière forme permet à la propriété à définir ailleurs dans la même classe. Cela signifie aussi qu'il n'y a pas d'avertissement si la propriété est pas définie dans le constructeur, et le champ est en lecture seule pour le CLR. Ce sont des différences subtiles, mais juste d'aller pour la deuxième forme, car il est plus simple et en ignorant les différences se sent comme un abus à moi, même si elle est mineure.

Heureusement, il est maintenant disponible en C # 6:

// Foo can only be set in the constructor, which corresponds to a direct field set
public int Foo { get; }

Answer 2

Il n'y a pas de « abus » dans tout simplement pas écrire le champ manuellement; et il est bon d'encourager tous les accès via la propriété (pas directement sur le terrain) de toute façon!

Le plus gros problème que je connaisse est avec sérialisation binaire , où il devient un peu difficile de revenir à un champ régulier sans la rendre version incompatible - mais ... utiliser un ;-P sérialiseur différent

Ce serait bien s'il y avait une « bonne » variante en lecture seule, et si vous ne l'avez pas besoin d'utiliser cteur-:this() enchaînant sur struct, mais .... meh!

Answer 3

Je ne l'ai pas vu tout abus de celui-ci. Et pour être honnête, je ne vois pas vraiment ce que vous voulez dire, que je ne vois pas comment cette syntaxe pourrait être abusée.

Answer 4

Je ne pense pas que les propriétés automatiques sont pires que les propriétés régulières en ce qui concerne l'encapsulation.

Si vous voulez dire que certains développeurs utilisent des propriétés publiques automatiques plutôt que des champs privés alors ceci est bien sûr faux et l'encapsulation des pauses ..