Should enum be refactored to a class when more functionality is requested?

Question

At this point I have the following code.

internal enum Genders
{
  Male,
  Female,
  NotSure,
  Other
}

I'm thinking about adding an extra functionality so that I can foreach all the values and return a String based on that. So, I'd go for the mapping as follows.

Male    -> "boy"
Female  -> "girl"
NotSure -> "oh-boy"
Other   -> "cow"

Should I refactor the enum into a class or is it recommended to just assign ToString values to the different enum states? I've googled it but didn't see any code examples for it, so I'm not sure if it's advisable to do that.

Perhaps it's better to create an auxiliary class and use a method like this?

private IEnumerable<String> GetGenders()
{
  yield return "boy";
  yield return "girl";
  yield return "oh-boy";
  yield return "cow";
}

Or am I just confusing myself and should stop immediately?

Answer 1

Consider adding an extension to the Enum instead.

You could for example, do like this:

Gender.Male.Description (which would return string "boy")

The extension looks like this:

    /// <summary>
    /// Defines an EnumExtensions type.
    /// </summary>
    public static class EnumExtensions
    {
        /// <summary>
        /// Gets the value from a DescriptionAttribute applied to the enum.
        /// </summary>
        /// <param name="value">Enum value.</param>
        /// <returns>DescriptionAttribute value, or null if no attribute is applied.</returns>
        public static string Description(this Enum value)
        {
            var type = value.GetType();
            var fieldInfo = type.GetField(value.ToString(CultureInfo.InvariantCulture));

            var descriptionAttributes = fieldInfo.GetCustomAttributes(typeof(DescriptionAttribute), false);

            return descriptionAttributes.Length > 0
                       ? ((DescriptionAttribute)descriptionAttributes[0]).Description
                       : null;
        }

Your enum would look like this:

public enum Gender
{
    [Description("boy")]
    Male,

    [Description("girl")]
    Female,

    [Description("oh-boy")]
    NotSure,

    [Description("cow")]
    Other
}

Answer 2

It's reasonable to add such functionality, but not necessarily in the way that you propose. I'd use a dictionary to map enum values to their translations, and add TWO methods:

1. A method that looks up a single enum in the dictionary and returns the (possibly localized) string for it.
2. Another method that returns all the values in the dictionary as an IEnumerable.

I think it's extremely likely that if you want a list of all the strings for an enum, you would also want to look up one particular enum. If you need both methods, you want to have a single implementation for the list of enum strings to ensure that the two methods can't get out of sync and that (of course) you Don't Repeat Yourself.

(We have to map to strings any of our enums that can be displayed to the user, because we can't use the built-in enum.ToString() since that is in "programmer language" and furthermore is not localized.)

Answer 3

Well, it depends on your personal preferences and the requirements of the application. One big advantage of enums is to define a limited set of numeric values that even the compiler and development environment are aware of, and replacing them with a collection of strings negates that. This might also be important if you want to store the enum value in a database field at some point.

If performance isn't a big issue, you could decorate your enum with DescriptionAttributes to associate them with string names, or any other metadata you want:

internal enum Genders
{
  [Description("boy")]
  Male,
  [Description("girl")]
  Female,
  [Description("oh-boy")]
  NotSure,
  [Description("cow")]
  Other
}

...and then retrieve the descriptions using reflection as needed. Not lightning fast, but I do this fairly often with labels that are going to be displayed in a WPF form, where a handful of GetCustomAttributes() calls are the least of my performance concerns. :)

If you want to get fancy, one advantage of this approach (as opposed to hard-coded strings) is that you can tie your descriptions to strings contained in the application resources (so you could, for example, have localized versions for different languages). I believe Microsoft takes this approach for some of their libraries (or am I thinking of something else?). And of course you can retrieve the name of the enum member as defined in your code simply by invoking ToString() on the enum value.

You can also enumerate over the members of an enum with the Enum.GetValues() method. So really, you can do the things you're looking for either way, it's just a matter of whether it's worth it to you to complicate things or keep them simple.

Answer 4

it depends on the level of complexity you need to implement. if it's just description in English you can use DescriptionAttributes as suggested in other  answers. If you need to support multiple languages, you have to use the localization resources( either in .resx files or in the database) - e.g. see http://www.codeproject.com/Articles/19953/Localizing-NET-Enums

However for more complicated scenarios using enum is not sufficient.

There are a few problems with enumerations : 

• Behavior related to the enumeration gets scattered around the application
• New enumeration values require shotgun surgery
• Enumerations don’t follow the Open-Closed Principle

(From http://lostechies.com/jimmybogard/2008/08/12/enumeration-classes/)

   

The blog post Enumeration classes described the public abstract class Enumeration and how to create derived classes from it.