Nested enum e conflitti di denominazione delle proprietà

Question

Ci sono alcune domande correlate here e here, ma in realtà non mi hanno dato risposte soddisfacenti. Il problema è che le enumerazioni nidificate in una classe in C# non possono avere lo stesso nome di una proprietà della classe. Il mio esempio:

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; } 
    ... 
} 

Ci sono alcune opzioni per hackerare intorno a questo, ma non mi sembra giusto.

Potrei spostare l'enum fuori dalla classe, ma poi diresti semplicemente Suit invece di Card.Suit, che mi sembra sbagliato. Che cos'è un Suit al di fuori del contesto di un Card?

li riuscivo a muovere al di fuori della classe e cambiarli in qualcosa di simile CardSuit e CardRank, ma poi mi sento come se fossi la cottura le informazioni di contesto nel nome della enum, quando questo dovrebbe essere gestita da una classe o nome dello spazio dei nomi.

potevo cambiare i nomi delle enumerazioni per Suits e Ranks, ma questo viola Microsoft's naming guidelines. E non sembra giusto.

Potrei cambiare i nomi delle proprietà. Ma a cosa? Mi sembra intuitivamente giusto dire che voglio dire .

È possibile spostare l'enumerazione in una classe statica separata denominata CardInfo contenente solo queste enumerazioni. Se non riesco a trovare qualcos'altro, penso che questa sia l'opzione migliore.

Quindi mi chiedo cosa hanno fatto le altre persone in situazioni simili. Sarebbe anche bello sapere perché questo non è consentito. Forse Eric Lippert o qualcuno potrebbe prendere in considerazione la decisione di vietarlo? Sembra che crei solo l'ambiguità all'interno della classe, e questo potrebbe essere risolto forzando l'uso di this.Suit per il nome della proprietà. (Simile al disambiguazione tra locali e membri.) Presumo che questo sia stato omesso a causa della cosa "every feature starts with -100 points", ma sarei curioso di discutere su questo argomento.

Answer 1

sarebbe anche bello sapere perché questo non è consentita. Forse Eric Lippert o qualcuno potrebbe prendere in considerazione la decisione di vietarlo?

Il punto della regola è garantire che non ci sia ambiguità all'interno della classe quando si cerca un nome. Alcune regioni di codice sono designate come definenti uno 'spazio di dichiarazione'. La regola fondamentale di spazi dichiarazione è non ci sono due cose dichiarati nello stesso spazio di dichiarazione hanno lo stesso nome (tranne che per i metodi, che deve differire di firma, non nome.)

fare eccezioni a questa regola rende le cose più confuse, non meno confuse. Sono d'accordo che è irritante che tu non possa avere una proprietà e una enum dello stesso nome dichiarata nello stesso spazio di dichiarazione, ma una volta che inizi a fare eccezioni, allora diventa un casino. Di solito è una proprietà piacevole che un nome in modo univoco identifica un gruppo di metodi, un parametro di tipo, una proprietà e così via.

Si noti che questa regola si applica alle cose dichiarato in uno spazio di dichiarazione, non le cose utilizzati in uno spazio di dichiarazione. È perfettamente legale dire "Suit Suit pubblico {get; set;}" purché il tipo Suit non sia dichiarato nello stesso spazio dichiarativo della proprietà. Quando qualcuno dice "Suit.X", capire se X è sul tipo (cioè X è un membro statico) o la proprietà (cioè X è un membro di istanza) è un po 'complicato. Vedere il mio articolo su come lo facciamo per i dettagli:

http://blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx

Answer 2

Preferisco denominare enumerazioni utilizzando un nome seguito da Opzioni. Nel tuo caso:

SuitOptions 
RankOptions 

Dopo tutto, l'enumerazione è solo una serie di possibili opzioni, giusto?

Si dovrà quindi:

myCard.Suit = Card.SuitOptions.Clubs; 

che a mio parere ha un senso e si è ancora in grado di sapere quando si visualizza il testo se è poi enum o proprietà.

Answer 3

Sposterei le enumerazioni al di fuori della definizione della classe e userei lo spazio dei nomi per indicare che si riferiscono alle carte. In genere non mi piace l'enumerazione annidata all'interno delle classi. Hai ragione riguardo alla pluralità, però: singolare per enumerazioni regolari, plurale per enumerazioni di bandiere.

Answer 4

Le tue enumerazioni sono fondamentalmente tipi di dati che hai definito. Non useresti "int" o "string" come nome di membro, quindi penso che sia ugualmente una cattiva idea usare i tuoi nomi enum e nomi di membri nel tuo caso.

Answer 5

Concordo con lo spostamento della definizione enum in un altro luogo.Attualmente, le enumerazioni sono visibili solo attraverso la carta, quindi se si voleva verificare la presenza di un asso, si avrebbe a che fare

if (card.CardSuit == Card.Suit.Ace) { } //need different name for Suit field 

Dove se si è spostato a una definizione autonoma, si potrebbe fare questo se l'hai fatta globale:

if (card.Suit == Suit.Ace) { } //no naming clashes, easier to read 

Answer 6

it't interessante vedere che mentre il Microsoft Naming Guidelines dicono si dovrebbe usare un nome singolare per la maggior parte le enumerazioni e nomi plurali per i campi di bit, the code sample for the enum keywordfa usa un nome plurale!

enum Days { Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday };