Every now and then, when I'm not thinking clearly, I'll find myself including a property with an enumerated type in my code, like this:

enum MyEnum { File, DB }

class MyControl : Control
{
   MyEnum saveType;

   public MyEnum SaveType 
   {
      get {return saveType;}
      set {saveType = value;}
   }
}

Enumerated properties like the one I've just shown are very common in .NET, which is unfortunate, because most of those properties are used to feed code that performs a capability query. Like this:

void DoSave(MyControl mc)
{
   switch (mc.SaveType)
   {
      case MyEnum.File : 
         // Save to a file...
         break;
      case MyEnum.DB :
         // Save to a database...
         break;      
   }
}

Can you see the problem(s) with the code sample above? Actually that's a trick question because the problems I'm alluding to are related to design - not code. I won't go into details (we would all be bored), just remember that capability queries are evil and should be avoided whenever possible. If you don't know what a capability query is then here are some links: Here, or Here or GOOGLE the term "capability query".

I know, I know, Microsoft uses this enumerated, capability query infested approach EVERYWHERE in .NET. That's why I blame Microsoft! Luckily, we don't have to follow Microsoft off that cliff with all the other lemmings. There are better ways of coding available to us!

Now, before I continue, don't think I'm saying that enumerations are bad. They aren't. They're fine - except when they are used to feed code that uses the enumerated information to perform a capability query. That's the part that's bad. Got It?

Alright, so what do we do then? Well, here is a better solution for the save example above. Notice that this approach does NOT perform a capability query:

abstract class SaveBase
{
   public abstract DoSave(); 
}

class FileSave : SaveBase
{
   public override DoSave()
   {
      // Save to a file.
   }
}

class DBSave : SaveBase
{
   public override DoSave()
   {
      // Save to a db.
   }
}

void DoSaveBetter(MyControl mc)
{
   Type type = // Convert the mc.SaveType property to a type.
   SaveBase saveBase = (SaveBase)Activator.CreateInstance(
                type
                );
   saveBase.DoSave(); // See ma, no CQ!
}

So why is the second approach better? Because I have isolated the code for file-saving into the FileSave class, and the code for db-saving into the DBSave class. I've also removed any specialized knowlege from the DoSaveBetter method - where it shouldn't have been in the first place. Even better, when I come back later and add another kind of save (say IsolatedStorage), I can just add a class called IsoSave to the project and I don't have to do ANYTHING to the DoSaveBetter method. Enough said? I hope so.