I mentioned that there are problems with enumerations above,
so by now you are probably wondering what those problems are. Well, one of them
is the same thing I said was great up above. Enumerations are basically just
numbers (please do not kill me for saying that). At the end of the day it is
easy to convert between enums and numbers. Sometimes it is safe and sometimes
it is not safe. Take a look at this simple code snippet which illustrates a
couple of the ways we can mess around with enums.
Listing 2: Converting Enumerations to Integers and
Integers to Enumerations
// This is safe, but a little bit odd
MyEnum myEnum = (MyEnum)(1 + (int)MyEnum.SomethingElse);
Console.WriteLine(myEnum);
// This is a really bad dangerous thing that can happen
MyEnum badEnum = (MyEnum)10;
Console.WriteLine(badEnum);
The first one works as we expect, it gives us the enum "AndNow"
and will write it to the screen. The second one, however, offers disturbing
results when it writes the number "10" to the screen. It actually
allows us to cast any integer value to one of our enumerations. That was not
very safe at all, and it was actually really easy to do. Enumerations give the
illusion of being safe here. Because we have the intellisense and
strongly-typed values, we believe an enumeration is a lot safer than it really
is.
In Combination with Lookup Tables
One thing I have seen used way more often than it should be
is a combination of lookup tables and enumerations. What I mean here is that an
enumeration is created which matches with a lookup table. In my opinion the use
of an enumeration implies that there will be logical decisions made based on
the enumeration. If you are using a lookup table, it means that this is simply
data, data likely to change. It also implies that the values in the table
should not have much logic associated with them.
The reason for this is that values in a table are easily
changed, and because of this, people assume the change is safe to make. We know
there are instances when changing the data can cause problems because logic
needs to be adjusted when adding, removing, or altering entries in the lookup
table.
Differences between lookup tables and enumerations cause
them to be incompatible in my opinion. If there will be a good amount of logic
based on these use an enumeration or an object. Do not have a lookup table. I
know it is nice for the database, but any changes to the database will cause
problems in the code.
Adding Information
Over time, people often try to add extra information to go
along with enumerations. Sometimes you will see people have added extra
attributes to enumerations for descriptions, colors, or something else. They are
trying to associate extra information with those enumeration values. Well this
is just one big sign that you need to move away from an enumeration. It is time
to decide whether that should just be a lookup table (if it is only data) or if
it should be a full-blown object (there is logic based on the values). If there
is logic based on those values you might want to do something similar to what I
outline next in this article.
