Enumeración de dos miembros vs. valor booleano

Question

Esta pregunta ha estado en mi mente por un tiempo, lo siento si parece subjetiva. Hay algunas desventajas en el uso de bool en propiedades públicas y constructores para objetos de datos. Considere el siguiente código como un ejemplo.

Usando bool:

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

    public Room(string name, bool bookable); 
} 

y el uso de esta clase

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

Este es adecuadamente funcional, no es sin embargo otra manera de ponerla en práctica:

Usando 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); 
} 

y el uso de esta clase

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

Para mí los dos aparecen funcionalmente equivalente, hay algunas ventajas y desventajas de cada uno, sin embargo:

• Al configurar las propiedades del método de enumeración es más verboso (puede inferir el uso de la enumeración solo del código)
• Las enumeraciones se pueden ampliar para admitir otros estados (particularmente útiles para una API)
• Las enumeraciones requieren considerablemente más tipeo (aunque lo reduce considerablemente)
• Las enumeraciones no se pueden usar en condicionales (es decir if (r.bookable)), aunque aprecio que esto es trivial de resolver.

¿Me falta algo, totalmente fuera de lugar? No estoy seguro de por qué esto me molesta tanto, ¡quizás yo también soy TOC por mi propio bien!

Answer 1

En su libro Refactoring, Martin Fowler explica por qué cree que las enumeraciones son un olor a código, y yo solo puedo estar de acuerdo. En su ejemplo, un mejor enfoque sería hacer un resumen de clase habitación:

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

    public abstract bool Bookable { get; } 
} 

entonces usted puede hacer que las clases derivadas BookableRoom y NonBookableRoom.

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 hay alguna posibilidad de que en el futuro puede haber más de las dos opciones iniciales, la adición de una tercera opción para una enumeración es mucho menos trabajo a continuación, cambiando todo bool a ENUM.

Answer 3

Simplemente por la legibilidad y la comprensión del código, buscaré enum en lugar de boolean.

Comparar BookingStatus.Bookable y true, por supuesto, usted entendería más leyendo BookingStatus.Bookable.

También como lo mencionado anteriormente, en caso de que en el futuro necesites agregar más opciones, enum sería más fácil de cambiar.

Answer 4

Para una propiedad, probablemente estaría de acuerdo. Sin embargo, en 'Código limpio', se indica (correctamente) que bool s ocultar intento cuando se utilizan como parámetros.Por ejemplo, un método de formato podría ser:

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

Cuando llamó a este aspecto:

Format(true, false, true); 

En cambio, sería mucho más fácil de leer como:

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) 
{ ... } 

Que a su vez hace que el llamar al:

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

(Recuerde que este es solo un ejemplo de cómo los parámetros de bool ocultan la intención; . Hay probablemente mejores formas de implementar el código anterior)

En su caso particular, notan la diferencia entre los dos constructor llama:

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

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