Using Objects Instead of Enumerations
page 2 of 4
by Brendan Enrick
Feedback
Average Rating: 
Views (Total / Last 10 Days): 25930/ 64

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
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.


View Entire Article

User Comments

Title: good   
Name: msoni
Date: 2010-01-05 8:31:11 AM
Comment:
i like it ......its a very nice aricle
Title: Good Article/Weak Arguments   
Name: Clint
Date: 2009-03-25 2:13:49 PM
Comment:
Good article on the usage between objects/enumerators; weak arguments on the reasons. The statement "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." collapses on itself. Regardless of implementation, values that dictate logic will usually have a negative impact on the coded logic.
Title: Great!!!   
Name: Gourik Kumar Bora
Date: 2009-02-20 2:07:39 AM
Comment:
Hi Enrick!!!
This is really cool...
thanks a ton....
Title: Thanks   
Name: Amir Arjmand
Date: 2009-02-18 7:48:28 PM
Comment:
Thanks Brendan,

Yes it did answer my question.
Title: RE: Two questions   
Name: Brendan Enrick
Date: 2009-02-18 9:14:52 AM
Comment:
@Amir sorry about that. I am using a lambda expression in that code snippet.
http://msdn.microsoft.com/en-us/library/bb397687.aspx

Array.Find(items.ToArray(), instance => instance.Name == name);

Basically you can read this line like this, "find from items.ToArray() an item where that item's Name property is equal to the variable name".

The variable "instance" is defined at that point to represent any item in the array we are searching.

I hope that answers your questions.
Title: Two questions   
Name: Amir Arjmand
Date: 2009-02-17 9:54:41 PM
Comment:
Hi everyone, I am new to C# and as I was going through the sample code, I came upon this statement

instance => instance.Name == Name

Could anyone please explain how exactlly this part of the code works. Where does that instance come from and what is => ? I could not find anything regarding that operator in msdn library for C#?

Thanks;
Title: RE: hmm   
Name: Brendan Enrick
Date: 2009-02-17 8:50:19 AM
Comment:
@dario-g thank you for making sure I don't pass along misinformation. Although, there is a big difference between casting an integer as an enum and passing an out of range integer to this object. If you read the code listing 6 above, you will notice that the object throws an argument out of range exception if the integer is out of range. This means that you will know there is a problem and what the problem is. You can also easily handle this exception.

If you used the enum, you might not run into any exceptions, and maybe later the code will save the integer value of the enum. You are going to have an invalid result stored somewhere and possibly not even know.

Thank you for the comment. Feedback is always welcome and appreciated.
Title: Thank you   
Name: Brendan Enrick
Date: 2009-02-17 8:43:40 AM
Comment:
@Joydip Thank you. I am glad you liked the article.
Title: Mousover   
Name: Brendan Enrick
Date: 2009-02-17 8:42:47 AM
Comment:
@Alex Simkin Yes, you are right the debugger works very well with enumerations. However, if you move the mouse a little bit more to the plus sign, it will reveal the values of the properties of this object. This will give you access to not just the name, but also the value of the object. This is more than you would get from an enum.
Title: Mr. ?   
Name: Alex Simkin
Date: 2009-02-16 2:35:11 PM
Comment:
In debugger, if you mouseover variable of enum type, you will find out the value instantly. If you mouseover MyObject variable, you will only see that it contains MyObject instance.
Title: Author and ASP.NET MVP   
Name: Joydip Kanjilal
Date: 2009-02-16 10:59:03 AM
Comment:
Excellent article! Keep posting such awesome articles.

Thanks,

Joydip
Title: hmm   
Name: dario-g
Date: 2009-02-16 3:34:56 AM
Comment:
MyObject obj = ...FromId(10); // This is a really bad dangerous thing that can happen

No difference.






Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2021 ASPAlliance.com  |  Page Processed at 2021-12-07 6:35:34 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search