Conflits d'énumération et de nommage

Question

Lors de l'utilisation d'une classe qui a un enum propriété, on obtient généralement un nom conflit entre le nom de la propriété et de type enum. Exemple:

enum Day{ Monday, Tuesday, ... }

class MyDateClass
{
   private Day day;

   public Day Day{ get{ return day; } }
}

Puisque seuls les drapeaux des enums devrait avoir pluriel des noms, noms enum "Jours" n'est pas la voie à suivre pour un non-drapeau de l'enum. Dans l'exemple ci-dessus, vous pourriez utiliser une variante comme "la Semaine", soit l'enum ou de la propriété. Mais dans le cas général, il n'y a pas de bonnes variations, alors vous vous retrouvez à l'aide des propriétés comme "FooMode" ou "BarKind" pour un objet avec enum propriétés de Foo et Bar type. Pas très élégante.

Comment avez-vous l'habitude nom des énumérations et des propriétés dans ce scénario?

---

Merci pour les réponses rapides. Une autre question: pourquoi n'est-il pas recommandé de nid public enum, et comment pensez-vous résoudre le nommage des questions si vous voulez nid public enum?

class Vehicle
{
  enum Kind{ Car, Bike }

  public Kind Kind{ get{ return ... } }
}

class Meal
{
  enum Kind{ Dessert, MainCourse }

  public Kind Kind{ get{ return ... } }
}

Dans le scénario ci-dessus, étant donné que les Repas et le Véhicule de partager le même espace de noms, je ne peux pas bouger "Genre" à l'extérieur de l'une des classes sans le renommer MealKind et VehicleKind respectivement. J'aime le look de

myVehicle.Kind = Vehicle.Kind.Car

Mais ce n'est pas ce que les lignes directrices recommandent. Quelle serait la meilleure pratique ici? Ne jamais utiliser imbriquée public enums et au lieu de les nommer VehicleKind etc.?

Answer 1

Il n'y a aucun conflit. En fait, le guide de style .NET Framework vous encourage à le faire , par exemple si vous avez une classe qui a une seule propriété d'un type (peu importe s'il s'agit d'une énumération ou d'une classe), vous devez alors la nommer de la même manière. Un exemple typique est une propriété Color de type Color. C'est bien, sauf s'il y a deux couleurs - dans ce cas, les deux devraient ajouter quelque chose au nom (c'est-à-dire BackColor et ForeColor, au lieu de Color et BackColor).

Answer 2

Tant que l'énumération n'est pas imbriquée dans MyDateClass, je ne vois pas que ce soit un problème. Il est loin d'être rare (selon mon expérience) d'avoir une propriété avec le même nom que le type qu'elle renvoie. Je vais voir si je peux trouver des exemples dans le cadre ...

EDIT: Premier exemple: DateTimeOffset.DateTime (pas une énumération, mais ce n'est pas pertinent)

Answer 3

Je suis d'accord avec Jon, je ne vois pas cela comme un problème. J'ai écrit du code comme celui-ci, même si je dirais que c'est assez rare sans rencontrer de problèmes, même du code marqué comme CLSCompliant (true).