page 2 of 4
by
Feedback
Average Rating:
Views (Total / Last 10 Days): 23874/ 55
Article Contents:

Some Problems with Enumerations

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

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.

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.

 « (Page 1) View Entire Article (Page 3) »