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.
- The Action* method contains state
- There are more than 2 functions which change their behavior based on the enum value
- All methods in the class change their behavior based on the enum
Anyone have a better set?