I like Enums and use them frequently for options and behavior. To an extent I use Enum’s to control behavior. For example

enum Kind {
    Kind1,
    Kind2,
    Kind3
}

class Example {
    private Kind m_kind;

    public int SomeAction() {
        switch (m_kind1) {
            case Kind.Kind1:
                return ActionForKind1();
            case Kind.Kind2:
                return ActionForKind2();
            case Kind.Kind3:
                return ActionForKind3();
            default:
                throw new InvalidOperationException("Invalid Kind");
        }
    }
}

This is an acceptable pattern and use for enums. However if you take a step back, what I’ve actually done here is use an enum to implement an adapter pattern. I’ve just been a bit lazy about it and not actually coded up the classes.

To an extent though this violates the principle of single use as Example now performs N different behaviors based upon the enum. But lets face it, if ActionForKindN() is just a simple 2 line function then is it really worth it to create and maintain an adapter pattern’ A purest would likely say yes but I’m more pragmatic and don’t believe so.

Once the functions reach a certain level of complexity though an adapter pattern is much more suitable. Over time I find that many of my similar patterns evolve to level.

Yet I struggle to define the point at which an adapter is suitable. After several recent experiences I started adapting the following rules. If any of them is violated then I switch from an enum based behavior to adapter based behavior.

  1. The Action* method contains state
  2. There are more than 2 functions which change their behavior based on the enum value
  3. All methods in the class change their behavior based on the enum

Anyone have a better set?


Share Post

Google+

comments powered by Disqus