Enumerazione di due membri rispetto al valore booleano

Question

Questa domanda ha in testa per un po 'di tempo, mi dispiace se sembra soggettiva. Ci sono alcuni svantaggi nell'usare bool in proprietà pubbliche e costruttori per oggetti dati. Considera il seguente codice come esempio.

Uso bool:

public class Room 
{ 
    public string Name { get; set; } 
    public bool Bookable { get; set; } 

    public Room(string name, bool bookable); 
} 

e l'uso di questa classe

Room r = new Room ("101", true); 

Questo è opportunamente funzionale, v'è tuttavia un altro modo di attuarla:

Uso enum :

public enum BookingStatus 
{ 
    Bookable, 
    NotBookable 
} 

public class Room 
{ 
    public string Name { get; set; } 
    public BookingStatus Bookable { get; set; } 

    public Room(string name, BookingStatus bookable); 
} 

e l'utilizzo di questa classe

Room r = new Room ("101", BookingStatus.Bookable); 

Per me i due sembrano funzionalmente equivalente, ci sono alcuni vantaggi e svantaggi di ogni comunque:

• Quando si impostano le proprietà del metodo Enum è più verbose (puoi dedurre l'uso dell'enum dal solo codice)
• Le enumerazioni possono essere estese per supportare ulteriori stati (particolarmente utili per un'API)
• Le enumerazioni richiedono una digitazione notevolmente maggiore (anche se la riduce notevolmente)
• Le enumerazioni non possono essere utilizzate in condizionali (ad es. se (r.bookable)), anche se apprezzo questo è banale da risolvere.

Mi manca qualcosa, totalmente fuori dal marchio? Non sono sicuro del motivo per cui mi infastidisce così tanto, forse sono troppo ossessivo per il mio bene!

Answer 1

Nel suo libro Refactoring, Martin Fowler spiega perché pensa che le enumerazioni siano un odore di codice, e posso solo essere d'accordo. Nel tuo esempio, un approccio migliore sarebbe quello di fare una classe astratta in camera:

public abstract class Room 
{ 
    public string Name { get; set; } 

    public abstract bool Bookable { get; } 
} 

classi BookableRoom e NonBookableRoom allora si può fare derivati.

public class BookableRoom : Room 
{ 
    public override bool Bookable 
    { 
     get { return true; } 
    } 
} 

public class NonBookableRoom : Room 
{ 
    public override bool Bookable 
    { 
     get { return false; } 
    } 
} 

Answer 2

Ih v'è alcuna possibilità che in futuro ci potrebbe essere più di le prime due opzioni, l'aggiunta di una terza opzione per un enum è un lavoro molto meno poi cambiando tutto bool a enum.

Answer 3

Semplicemente a causa della leggibilità e della comprensione del codice, andrò per enumerare anziché booleano.

Confronta BookingStatus.Bookable e true, ovviamente capirai di più leggendo BookingStatus.Bookable.

Analogamente a quanto detto da Fforw, in futuro potrebbe essere necessario aggiungere più opzioni, enum sarebbe più semplice da modificare.

Answer 4

Per una proprietà sarei probabilmente d'accordo. In "Codice pulito", tuttavia, viene indicato (correttamente) che l'intento di nascondino di bool viene utilizzato come parametri.Ad esempio, un metodo di formattazione potrebbe essere simile:

public void Format(bool pBold, bool pItalic, bool pUnderline) 
{ ... } 

Quando ha chiamato questo appare come:

Format(true, false, true); 

Invece sarebbe molto più leggibile come:

public enum BOLD { BOLD, NOT_BOLD } 
public enum ITALIC { ITALIC, NOT_ITALIC } 
public enum UNDERLINE { UNDERLINE, NOT_UNDERLINE } 

public void Format(BOLD pBold, ITALIC pItalic, UNDERLINE pUnderline) 
{ ... } 

Che poi fa la chiamata simile:

Format(BOLD.BOLD, ITALIC.NOT_ITALIC, UNDERLINE.NOT_UNDERLINE); 

(Ricordare che questo è solo un esempio di come i parametri bool nascondono l'intento; . Ci sono modi probabilmente migliori per l'attuazione del codice di cui sopra)

Nel vostro caso particolare, notare la differenza tra i due costruttore chiama:

// enum; intent is clear 
Room r = new Room ("101", BookingStatus.Bookable); 

// bool; true what? 
Room r = new Room("101", true);