15

I've often seen and used enums with attached attributes to do some basic things such as providing a display name or description:

public enum Movement {
    [DisplayName("Turned Right")]
    TurnedRight,
    [DisplayName("Turned Left")]
    [Description("Execute 90 degree turn to the left")]
    TurnedLeft,
    // ...
}

And have had a set of extension methods to support the attributes:

public static string GetDisplayName(this Movement movement) { ... }
public static Movement GetNextTurn(this Movement movement, ...)  { ... }

Following this pattern, additional existing or custom attributes could be applied to the fields to do other things. It is almost as if the enum can work as the simple enumerated value type it is and as a more rich immutable value object with a number of fields:

public class Movement
{
    public int Value { get; set; } // i.e. the type backing the enum
    public string DisplayName { get; set; }
    public string Description { get; set; }
    public Movement GetNextTurn(...) { ... }
    // ...
}

In this way, it can "travel" as a simple field during serialization, be quickly compared, etc. yet behavior can be "internalized" (ala OOP).

That said, I recognize this may be considered an anti-pattern. At the same time part of me considers this useful enough that the anti might be too strict.

Kit
  • 20,354
  • 4
  • 60
  • 103
  • 4
    Are you asking if it's a bad idea to use this pattern in places where you wouldn't otherwise be using an enum? It's a great pattern for associating meta-data to enum values. It's not so great as a replacement for classes. – Kirk Woll Oct 24 '11 at 20:47
  • It could be considered an "abuse" of the language; almost like using `dynamic` all the time when not warranted for example. – Kit Oct 24 '11 at 20:47
  • 1
    Not exactly on point (hence the comment), but I have misgivings about encoding text to be displayed in an attribute -- or anywhere near an entity class, for that matter. For one thing, I think it grossly violates "seperation of concerns" and for another, there's no apparent way to localize it. Alas, MS seems to encourage this sort of thing, so maybe I'm out to lunch. – Daniel Pratt Oct 24 '11 at 20:47
  • @Daniel, extension methods are by definition not anywhere near the entity class. The UI-specific extension methods can even live entirely in the UI layer. – Kirk Woll Oct 24 '11 at 20:49
  • 1
    @KirkWoll I was referring to the 'DisplayName' attributes. – Daniel Pratt Oct 24 '11 at 20:50
  • Seems like a good fit for http://codereview.stackexchange.com ... – IAbstract Oct 24 '11 at 20:52
  • @DanielPratt - a reasonable vote for anti-pattern. Both yours and Kirk's points underscore why I asked. – Kit Oct 24 '11 at 20:53
  • @IAbstract - actually I agree. Someone with rep want to migrate it? – Kit Oct 24 '11 at 20:55
  • This isn't related to C# specifically but Java enums are, in essence, classes in a way where you give them properties and methods just like a class yet they function like an enum. I like this design and it's very useful IMO but I could see it being abused. The two best examples (IMO) that I've seen is in Minecraft where an enum is used to represent the material an item was made from and has a max number of uses, and for a gender with a simple `.hisHer()` method and others that would return gender specific Strings. – Brandon Buck Oct 24 '11 at 21:04
  • You'll discover the anti-pattern when the boss decides to no longer ignore two billion customers in Asia. – Hans Passant Oct 24 '11 at 22:06
  • @Kit: You can flag and ask for it to be migrated. – IAbstract Oct 24 '11 at 23:28
  • Added a bit to my answer re: serialization. – FMM Mar 07 '12 at 18:27

2 Answers2

7

I would consider this to be a poor pattern in C# simply because the language support for declaring and accessing attributes is so crippled; they aren't meant to be stores of very much data. It's a pain to declare attributes with non-trivial values, and it's a pain to get the value of an attribute. As soon as you want something remotely interesting associated with your enum (like a method that computes something on the enum, or an attribute that contains a non-primitive data type) you either need to refactor it to a class or put the other thing in some out-of-band place.

It's not really any more difficult to make an immutable class with some static instances holding the same information, and in my opinion, it's more idiomatic.

mqp
  • 70,359
  • 14
  • 95
  • 123
  • It's not difficult, no, in terms of *declaration* of an enum vs. an immutable, rich object, and there is pain for the implementer of the rich-enum, but what about *usage*? Though your point on *idiom* sits well with me. – Kit Oct 24 '11 at 22:53
  • Good point about writing idiomatic code. You always want to write code that plays nice with the language / framework that it lives in. – FMM Oct 25 '11 at 01:55
5

I'd say it's an anti-pattern. Here's why. Let's take your existing enum (stripping attributes for brevity here):

public enum Movement
{
    TurnedRight,
    TurnedLeft,
    Stopped,
    Started
}

Now, let's say the need expands to be something a little more precise; say, a change in heading and/or velocity, turning one "field" in your "pseudo-class" into two:

public sealed class Movement
{
    double HeadingDelta { get; private set; }
    double VelocityDelta { get; private set; }
    // other methods here
}

So, you have a codified enum that now has to be transformed into an immutable class because you're now tracking two orthogonal (but still immutable) properties that really do belong together in the same interface. Any code that you'd written against your "rich enum" now has to be gutted and reworked significantly; whereas, if you'd started with it as a class, you'd likely have less work to do.

You have to ask how the code is going to be maintained over time, and if the rich enum is going to be more maintainable than the class. My bet is that it wouldn't be more maintainable. Also, as mquander pointed out, the class-based approach is more idiomatic in C#.

Something else to consider, as well. If the object is immutable and is a struct rather than a class, you get the same pass-by-value semantics and negligible differences in the serialization size and the runtime size of the object as you would with the enum.

FMM
  • 4,289
  • 1
  • 25
  • 44