The Switch Statement

I first cut my teeth with OO design and development using C++ and an operating system called QNX. To be honest, it took me at least 5 years to fully make the transfer from procedural programming to OO.

I went through the “normal” stage of thinking that I understood OO, which I term procedural code with classes wrapping them up. After constant development, I finally got that basically in OO everything is an object. This was brought home to me when I worked on a project where a “CMessageUnsignedInt” class was created.

The class involved was a message ID, to signify events within the system. Other than the “event” (unsigned int) there was no other payload. I was the test team manager at the time and hence not involved in the design and development, but I told them that it was a mistake and that they should specialise out each event as an object. I had many discussions with the development team leader about this.

The system was large and complex, with several subsystems involved; this meant that the events (CMessageUnsingedInt) were being processed in many places. To distinguish which actual event it was, there were many switch statements, some of which were subsets of the complete list. So to add a new event, you either had to tell everyone what the new event was and what it meant, or to go rummaging through the code yourself.
This has, subsequently, led me to a bold statement! The switch statement does not belong in an OO project. If you have one, your design is flawed. My reasoning is this, and I will base it on the “message” paradigm, as it easy to understand – typically a message is an input either externally (Serial/IP etc) or between subsystem/separate threads of execution, but it applies across the board.

So when a message is received, what do you do with it? Well, in the example cited above, we should have had specialised a “CEventMessage” from which all of the actual events are specialised. Each CEventMessage has an abstract “IsThisYours” method. All of the event messages are registered with a factory. When a message is received you iterate through the factory asking “IsThisYours”. If it is, then a valid object is returned which you process accordingly.

The example cited is trivial, but imagine if the message has a payload. Now the specialised “IsThisYours” method can also unserialise the data and return a validated and correct object.

In addition, sometimes the “message” won’t have an ID (if coming from an external source), it may just be a string of bytes, “IsThisYours” can attempt to deconstruct the bytes and determine if it is valid to that Class.
Anyway, I’ve rambled a bit! My essential point is this: In OO everything is a class and the information belongs in that class. If you have a switch statement, then the data is now outside of the class. Create an abstraction, put it in a factory and iterate through it. Now all you need to do to add a new message, is add a new message. Clearly something somewhere will have to do something with it, but often the message can be treated generically (data logging is the simplest example) but, with the addition of additional abstract methods, displayed on a UI etc.
Clearly with .Net and Type Identification from a loaded DLL adding a message is even simpler.

I worked under the above development team leader on a subsequent project. There was a team of five of us. When I left after three years development I “grepped” all of the source. Not one switch statement to be found.