Enumeration of two elements in relation to a logical value

Question

This question has been thought over for some time, sorry if it seems subjective. There are some drawbacks to using bool in public properties and constructors for data objects. As an example, consider the following code.

Using bool:

public class Room { public string Name { get; set; } public bool Bookable { get; set; } public Room(string name, bool bookable); } 

and use of this class

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

This is suitable functionality, but there is another way to implement it:

Listing Usage:

 public enum BookingStatus { Bookable, NotBookable } public class Room { public string Name { get; set; } public BookingStatus Bookable { get; set; } public Room(string name, BookingStatus bookable); } 

and use of this class

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

For me, these two are functionally equivalent, but there are some advantages and disadvantages:

• When setting properties, the Enum method is more detailed (you can conclude about using an enumeration only from code)
• Enumerations can be extended to support additional states (especially useful for API)
• Enumerations require significantly more typing (although they significantly reduce this)
• Enumerations cannot be used in conditional expressions (i.e. if (r.bookable)), although I believe this is trivial for a solution.

I missed something, did not notice at all? I'm not sure why it hurts me so much, maybe I'm too OCD for my own good!

Answer 1

In his book "Refactoring," Martin Fowler explains why he believes that transfers are the smell of code, and I can only agree. In your example, it would be best to make an abstract class of the class:

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

You can then create the BookableRoom and NonBookableRoom classes.

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

Answer 2

Just because of the readability and understanding of the code, I will switch to enum instead of boolean.

Compare BookingStatus.Bookable and true , of course, you will understand that you read more BookingStatus.Bookable .

As well as what was mentioned above, if in the future you may need to add additional parameters, it will be easier to change the list.

Answer 3

I have a chance that in the future there may be more than the original two parameters, adding the third option to the enumeration, a lot less work, and then change all the bool to an enumeration.

Answer 4

For the property, I would probably agree. In the "Clean Code" it is indicated (correctly) that bool hide the intention when used as parameters. For example, a formatting method might look like this:

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

When called, it looks like this:

 Format(true, false, true); 

Instead, it would be much more readable:

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

What then causes the call:

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

(Remember, this is just an example of how bool options hide intent, there may be more efficient ways to implement the above code.)

In your specific case, pay attention to the difference between the two constructor calls:

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