Ruminations About Enumerations

I have been busy refactoring my Windows Phone 7 game and I started using enumerations more to increase the readability of my code.  Some of the game rules are so complex and convoluted that I found enumerations a very handy way to express my intentions.  For example, consider this:

1 
2 if (targetUnit.Equipment.EquipmentSubClass.EquipmentClass.EquipmentGroup.EquipmentGroupId == 0
3     && targetTile.Terrain.TerrainType.TerrainTypeId == 1
4     && targetUnit.CanMove
5     && targetUnit.CanAttack)
6 {
7     this.menuFactory.ShowUpgrade = true;
8 }

to this:

1 if (targetUnit.Equipment.EquipmentGroupEnum == EquipmentGroupEnum.Land 
2     && targetTile.Terrain.TerrainTypeEnum == TerrainTypeEnum.Port
3     && targetUnit.CanMove
4     && targetUnit.CanAttack)
5 {
6     this.menuFactory.ShowUpgrade = true;
7 }

If you dropped into this project, which one would you understand quicker?  This readability comes with a cost though – I now have to create separate files of code that I need to maintain. A second problem is that I am duplicating data – the lookup values from my database are hard-coded into the business layer.  If I add a value to the database and want to use it in my business logic, I will have to recompile.  A final problem is one of naming – I have a class and an enum that means exactly the same thing but I don’t want to name them the same thing (see Domain specific language), even if used different namespaces.  In this example, I appended “enum” to the suffix of the class: TerrainType and TerrainTypeEnum.  Taking these problems in order:

Problem #1: separate code to maintain – Yes, though it seems like a small price to pay.  The trend in our industry is to have more classes/things that do only 1 thing (Single Responsibility Principle) so a large number of files is a natural side-effect.  Fortunately, VS2010 makes file cataloging easy so it does not really get in the way of developer productivity.

Problem #2: duplicate data.  Yes, but…. The enums are data that is to be used in design time (as part of the business/programming logic).  The data that is stored in the classes are for the end-user.  That data is volatile  and changes can be reflected at run-time without recompiling, mostly.  I would maintain that due to the separate audiences, it is ok to have 2 “things” represent the same data.  I would also argue that enums are only for classes that are lookups – reference tables in your database for example.  In that case, even if you make a change to a reference table and want to implement some additional logic in your code, guess what?  You are still recompiling.  You just have to remember to add that value to the enum – which should be fairly straightforward if your spent some time to make sure your projects are consistent and well-organized.

Problem #3 Naming.  Since the project now has two things (the class and the enum) representing the same data, what should be done about naming.  The .NET API/Framework Design Guidelines is not much help here – Color is an enum only, there is no color class.  If more colors are added/created, they are NOT reflected in the .NET Color enum, you have to use the RGB values.  I  appended the enum suffix on the name of the class because it is pretty clear the intention of the files:

I punted – but at least I punted consistently.

After all that, I find that my code is MUCH more readable and I am writing business rules much faster and finding my logic errors much quicker. 

As a side note, do you notice that some organizations they dub “SMEs” that are just walking enums?  For example, they can recite what ICD-9 code for a broken leg off of the top of their head.  I wonder if a well-designed system replaces this kind of expert….