Using Objects Instead of Enumerations
Published: 16 Feb 2009
Enumerations are a commonly used and known tool built into programming languages. They are however not the only way of doing things. In this article, Brendan outlines an alternative to using enumerations. He discusses some of the reasons why you might use an alternative and uses source code to explain how to achieve a comparable equivalent to enumerations.
by Brendan Enrick
Average Rating: 
Views (Total / Last 10 Days): 25890/ 60


Enumerations are one of many useful tools at the fingertips of developers. Most of us have been using them for years. Because they are so common and easy to use, I believe we sometimes overuse them. An enumeration at its core is merely a number value. Try this in C# and you will see how easy it is to convert between enumerations and integer values. Enumerations are useful because they are named collections of values which are associated under the surface with integer values.

This example shows how one could quickly and easily print out the names and number values of an enumeration.

Listing 1: Simple Enumeration Console Output

using System;
class Program
    static void Main(string[] args)
    public static void HaveFunWithEnums()
internal enum MyEnum

That is some very easy code, and I think most people have probably seen enumerations printed by name as well enums converted to integers and their values used. So if enums are so great, why would I write an article talking about a way of avoiding them? Well, I would first like to say that I am a big fan of enums. I think they are quite useful; they just have some risks as well as some circumstances under which they fall a little bit short as far as software design is concerned.

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);
// This is a really bad dangerous thing that can happen
MyEnum badEnum = (MyEnum)10;

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.

Creating an Object-based Solution

What are the properties of enumerations we want to be able to replicate?

·         Strongly typed access

·         Unchanging at runtime

·         Name and value pairing

·         Customizable values

·         Conversion to integers

·         Get by value

·         Get by name

·         List all

So in order to replace our enumeration we are going to need to include these. Since we are using objects, the first one should be easily done. Our object will need to have at least two properties for the Name and the Value. So if we were just going to create a regular object we would have something like this.

Listing 3: Normal Object

public class MyObject
  public int Id { get; set; }
  public string Name { get; set; }

With this object we could create instances of it at runtime, but this is not what we want yet. The next step is making sure that we have a set of instances to start with and no more can be created. To do this we will make out constructor private. With the constructor private, we will need to declare the instances of this object inside the class, so the instances will need to be static. We will need to make sure that all of the values can be passed into the constructor so the instances can be created easily as static properties of the class This has the nice effect of allowing us to access them using ClassName.InstanceName. That naming convention will look similar to the one for enumerations which is Enumname.InstanceName.

Our new code which uses static instances and a private constructor looks like this.

Listing 4: Static Instances and Private Constructor

public class MyObject
    public static MyObject MyObjectOne = new MyObject(1, "MyObjectOne");
    public static MyObject MyObjectTwo = new MyObject(2, "MyObjectTwo");
    public static MyObject MyObjectThree = new MyObject(3, "MyObjectThree");
    public int Id { get; private set; }
    public string Name { get; private set; }
    private MyObject(int id, string name)
        Id = id;
        Name = name;

This object will already do a lot of what we need. It maintains a limited set, is strongly typed, has a name, has a value, you have control over the values for each, and the Id property lets you have it as an integer. Now we need to be able to get these based on the Id and the Name, and we also need to maintain a list of them.

Listing all of the values is useful for displaying them in different places such as a DropDownList or something similar.

Listing 5: Listing All of the Instances

public static List<MyObject> ListAll()
   return new List<MyObject>

For this it is pretty easy to just put them in a list like this or something similar. Not too difficult to maintain, it gives you good control of what is in the list.

Getting the instance of the object by Id and by Name is also pretty easy. With very little effort we are able to get them, and we throw some exceptions if we receive invalid method arguments.

Listing 6: FromId and FromName

public static MyObject FromId(int id)
    List<MyObject> items = ListAll();
    MyObject match = Array.Find(items.ToArray(), instance => instance.Id == id);
    if (match == null)
        throw new ArgumentOutOfRangeException(string.Format(
            "Id '{0}' is invalid for {1}", id, typeof(MyObject).Name));
    return match;
public static MyObject FromName(string name)
    List<MyObject> items = ListAll();
    MyObject match = Array.Find(items.ToArray(), instance => instance.Name == name);
    if (match == null)
        throw new ArgumentOutOfRangeException(string.Format(
            "Name '{0}' is not a valid {1}", name, typeof(MyObject).Name));
    return match;

At this point our object does pretty much everything we want it to do. This class is fairly testable, and is designed in such a way that we can add extra information to it. We can also add extra properties for any attributes we want like descriptions.


For many people, an enumeration is the correct solution, and for others the solution is a lookup table. I do not think those should be used together, but some people might have a reason to do so. It is important to keep in mind the circumstances of your exact situation when deciding, because I think there are plenty of times when an object should be used instead of either one.

Using the method outlined in this article should allow you to get around using an enumeration or a lookup table. It is an alternative that lets you extend enumerations, and has some other pros and cons. In some ways they are not as easy to work with as enumerations, but they are also safer in some ways.

You can find more content from this author on his blog.

User Comments

Title: good   
Name: msoni
Date: 2010-01-05 8:31:11 AM
i like it ......its a very nice aricle
Title: Good Article/Weak Arguments   
Name: Clint
Date: 2009-03-25 2:13:49 PM
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
Hi Enrick!!!
This is really cool...
thanks a ton....
Title: Thanks   
Name: Amir Arjmand
Date: 2009-02-18 7:48:28 PM
Thanks Brendan,

Yes it did answer my question.
Title: RE: Two questions   
Name: Brendan Enrick
Date: 2009-02-18 9:14:52 AM
@Amir sorry about that. I am using a lambda expression in that code snippet.

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
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#?

Title: RE: hmm   
Name: Brendan Enrick
Date: 2009-02-17 8:50:19 AM
@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
@Joydip Thank you. I am glad you liked the article.
Title: Mousover   
Name: Brendan Enrick
Date: 2009-02-17 8:42:47 AM
@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
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
Excellent article! Keep posting such awesome articles.


Title: hmm   
Name: dario-g
Date: 2009-02-16 3:34:56 AM
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  |  Page Processed at 2021-11-26 11:12:23 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search