53: Enumerations And Bit Flags.

Enumerations allow you to name different related options. The names can refer to a single option or you can use what you now know about bits to combine them into flags. With flags, you can have multiple enumeration options that you can work with as a single value. Whether you want to keep track of colors with enumeration values red, green, blue, etc. or you want to keep track of what a piece of armor is made out of as this episode describes, enumerations allow you to provide more meaningful names to these values. It’s a lot more readable and less error prone than returning an integer directly and then trying to remember what value that integer represents. Give your values actual names with an enumeration. Enumerations declared like this can only take on a single value at a time. In other words, the color can be either red, or it can be blue, etc. But it can’t be both red and blue. At least not with a simple enumeration. If you instead carefully choose the numeric values for each value name so that the numeric values don’t conflict with one another at the binary level, then they can be combined. This is called a flag based enumeration and the enumeration values themselves are called flags. You choose values so they each have a single 1 binary digit and make sure that each flag value uses a different binary digit. You’ll want to use powers of two since these are the values that align with the binary place holder positions. Should your first flag be given the value of zero? Well, only if you want or need to be able to express the concept that none of the other flags currently apply. That could be important and if so, you probably want to consider naming this value “none” or “empty” or something that conveys the meaning of an absence of a value. You might also want to define enumeration values that are not intended to be used as flags but as a mask in case you need to work with certain groups of flags. Maybe certain flag combinations have special meaning or you just want to categorize them. The episode explains more about this. You can listen to the full episode or read the full transcript below. Transcript This is a common design decision especially with object-oriented programming. For example, should you have a base class called Armor and then separate derived classes for LeatherArmor, ChainArmor, or SteelArmor? Or should you just have a single class called Armor that know what type of armor it is? There’s no right answer and it will depend on your situation. If you decide to go with the second approach and have just a single Armor class, then how will you express the type of armor? One approach that I don’t recommend is you could have methods called isLeather, isChain, and isSteel that each return a boolean true or false. This imposes a horrible experience for any code trying to use your class because it has to call each of these methods one after another until one of them returns true. Imagine trying to play 20 questions with a 5 year old. Is it a dog? No. Is it a cat? No. Is it a tree? No. And what do you do when a new kind of armor comes along? Say DragonArmor. You now have to add a new method isDragon and then modify all the other code to start probing for this new type as well. A much better approach is to create a new type called an enumeration. This is a custom user-defined type just like how your classes are types. But instead of being able to add a bunch of data and methods to an enumeration, all it does is provide you with a means to map your own names to values. Enumerations don’t support multiple values. What I mean is that you can’t have an enumeration with some ints and a char and maybe a few bools. That would be a class. An enumeration has just a single value type and it gives you the ability to name specific values. With the Armor example, what we need is an enumeration called ArmorType. And we can then add values leather, chain, and steel