Hay algunas preguntas relacionadas here y here, pero realmente no me dieron respuestas satisfactorias. El problema es que los enumerados anidados en una clase en C# no pueden tener el mismo nombre que una propiedad de la clase. Mi ejemplo:Enumerados y conflictos de nomenclatura de propiedades
public class Card
{
public enum Suit
{
Clubs,
Diamonds,
Spades,
Hearts
}
public enum Rank
{
Two,
Three,
...
King,
Ace
}
public Suit Suit { get; private set; }
public Rank Rank { get; private set; }
...
}
Hay algunas opciones para hackear esto, pero no me parecen correctas.
Podría mover las enumeraciones fuera de la clase, pero solo diría Suit
en lugar de Card.Suit
, lo cual me parece incorrecto. ¿Qué es un Suit
fuera del contexto de un Card
?
que podía moverlos fuera de la clase y cambiarlos a algo así como CardSuit
y CardRank
, pero entonces me siento que estoy horneando información de contexto en el nombre de la enumeración, cuando esto debe ser manejado por una clase o nombre del espacio de nombres.
Podría cambiar los nombres de las enumeraciones a Suits
y Ranks
, pero esto infringe Microsoft's naming guidelines. Y simplemente no se siente bien.
Podría cambiar los nombres de las propiedades. Pero a que? Me parece intuitivamente correcto querer decir Suit = Card.Suit.Spades
.
Podría mover las enumeraciones en una clase estática separada llamada CardInfo
que contiene solo estas enumeraciones. Si no puedo encontrar otra cosa, creo que esta es la mejor opción.
Así que me pregunto qué han hecho otras personas en situaciones similares. También sería bueno saber por qué esto no está permitido. ¿Tal vez Eric Lippert o alguien podría intervenir en la decisión de prohibirlo? Parece que solo crea la ambigüedad dentro de la clase, y esto podría resolverse forzando el uso de this.Suit
para el nombre de la propiedad. (Similar a la desambiguación entre los lugareños y los miembros.) Supongo que esto se dejó de lado debido a la cosa "every feature starts with -100 points", pero me gustaría tener curiosidad sobre las discusiones al respecto.
Gracias por sus comentarios, a todos. Voy con 'CardInfo', pero no creo que haya una respuesta canónica aquí. Hay muchas opciones decentes, y creo que todo se reduce al estilo. –
Anidar 'enum' está bien si va a usarlos solo (¿en su mayoría?) Dentro de la clase. Luego debe nombrar 'enum' * ligeramente * de manera diferente (agregando * Tipo *, * Modo *, * Opción *, etc. al nombre) para evitar conflictos de nombre con el campo/propiedad. Si habrá muchos usuarios de ese 'enum' fuera de la clase, entonces anidar es una mala idea. Puede declararlo en el mismo archivo cs (para tener al menos algún tipo de relación con la clase donde se usa). El anidamiento no es deseable en wpf también (no necesariamente 'enum', pero en general). – Sinatr