Moving Beyond Enumerations
page 3 of 5
by Steven Smith
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 35344/ 88

Extending Enums With Attributes

You can add a *little* bit of behavior to enums through the use of attributes and reflection.  One common approach to the problem of displaying enums in a user-friendly manner is to add an attribute that can be used for display purposes.  You can create your own attribute, but it's probably better to use one that already exists and is well-suited to this purpose, such as the System.ComponentModel.Description attribute.  You can add it to any or all of your enumeration values in order to specify the "friendly" name that you want to display in your application.  The Role enum would then look like this (note the addition of a few more roles that I'll get to in a moment):

Now we can create a new method to help use fetch the description of a given enum.  This one is borrowed from this post.

If we adjust our method for displaying the enumerations, we'll now get "Sales Representative" output as we wanted.

You can of course continue down this road for as long as you wish, but personally I draw the line with one attribute.  If your enumeration's items each require 2 or more attributes, I would argue that you have stepped beyond capabilities of the enum type, and that you should upgrade to a class.  The additional behavior required of enums can come in many forms, but one I've seen frequently relates to visibility of options to end users.

As you saw above, there are now two Secret roles that should not be displayed with the other roles.  Not only that, but additional roles are also planned, some of which will be visible and some not (such as the new Manager role, which should be visible).  Our initial test of the new requirement that Secret roles not be displayed fails:

We could fix it in the DisplayFriendlyNames() method by adding individual checks for each role, but this gets ugly quickly.  Better would be if there were some kind of IsVisible property on the enum.  We could again turn to attributes, and perhaps create a [Visible(false)] or similar for the purpose, but as I noted, I draw the line with one attribute.


View Entire Article

User Comments

Title: Good Catch   
Name: Steve Smith
Date: 2011-08-30 7:56:15 PM
Comment:
@Ian,
Good catch. Yes, those fields should be readonly, of course.

Thanks!
Steve
Title: public static roles should be readonly   
Name: Ian Mercer
Date: 2011-08-30 5:01:05 PM
Comment:
Totally agree that enums should be replaced with classes as soon as they stop being enums. One improvement to your class would be to make all the values readonly, e.g.

public static readonly Author ...






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


©Copyright 1998-2019 ASPAlliance.com  |  Page Processed at 2019-09-17 11:19:12 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search