views:

213

answers:

4

This question has in the back of my mind for some time, sorry if it appears subjective. There are some disadvantages in using bool in public properties and constructors for data objects. Consider the following code as an example.

Using bool:

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

    public Room(string name, bool bookable);
}

and the use of this class

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

This is suitably functional, there is however another way to implement it:

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

and the use of this class

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

To me the two appear functionally equivalent, there are some advantages and disadvantages of each however:

  • When setting properties the Enum method is more verbose (you can infer the usage of the enum from the code alone)
  • Enumerations can be extended to support further states (particularly useful for an API)
  • Enumerations require considerably more typing (although reduces this vastly)
  • Enumerations can not be used in conditionals (i.e. if (r.bookable)), although I appreciate this is trivial to resolve.

Am I missing something, totally off the mark? I am not sure why this bugs me so much, perhaps I am too OCD for my own good!

A: 

You're giving the answers yourself. I don't know what to say more.

Stefan Steinegger
however I am the sole programmer in my organisation. For me an important part of learning is finding out what other people think about some thing, there may be things that I havn't throught through or flaws in my arguments.
Richard Slater
+3  A: 

In his book Refactoring, Martin Fowler explains why he thinks enums are a code smell, and I can only agree. In your example, a better approach would be to make an abstract Room class:

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

     public abstract bool Bookable { get; }
}

Then you can make derived BookableRoom and NonBookableRoom classes.

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

public class NonBookableRoom : Room
{
    public override book Bookable
    {
        get { return false; }
    }
}
Mark Seemann
Strong point, and a method I have used else where. I presume this wouldn't work very well with something like Entity Framework? However it would certainly map very well onto something like a SharePoint list.
Richard Slater
+3  A: 

Ih there is any chance that in the future there might be more than the initial two options, adding a third option to an enum is a lot less work then changing all bool to enum.

fforw
That's what he already said in his answer (second point in the bullet list).
Stefan Steinegger
except for the "plan for the future" aspect.
fforw
+2  A: 

Simply because of readability and understanding of the code, I'll go for enum instead of boolean.

Compare BookingStatus.Bookable and true, of course you would understand more reading BookingStatus.Bookable.

Also like what fforw mentioned, in case in future you might need to add more options, enum would be easier to change.

thephpdeveloper