Do polymorphism or conditionals promote better design?

Question

I recently stumbled across this entry in the google testing blog about guidelines for writing more testable code. I was in agreement with the author until this point:

Answer 1

Switches and polymorphism does the same thing.

In polymorphism (and in class-based programming in general) you group the functions by their type. When using switches you group the types by function. Decide which view is good for you.

So if your interface is fixed and you only add new types, polymorphism is your friend. But if you add new functions to your interface you will need to update all implementations.

In certain cases, you may have a fixed amount of types, and new functions can come, then switches are better. But adding new types makes you update every switch.

With switches you are duplicating sub-type lists. With polymorphism you are duplicating operation lists. You traded a problem to get a different one. This is the so called expression problem, which is not solved by any programming paradigm I know. The root of the problem is the one-dimensional nature of the text used to represent the code.

Since pro-polymorphism points are well discussed here, let me provide a pro-switch point.

OOP has design patterns to avoid common pitfalls. Procedural programming has design patterns too (but no one have wrote it down yet AFAIK, we need another new Gang of N to make a bestseller book of those...). One design pattern could be always include a default case.

Switches can be done right:

switch (type)
{
    case T_FOO: doFoo(); break;
    case T_BAR: doBar(); break;
    default:
        fprintf(stderr, "You, who are reading this, add a new case for %d to the FooBar function ASAP!\n", type);
        assert(0);
}

This code will point your favorite debugger to the location where you forgot to handle a case. A compiler can force you to implement your interface, but this forces you to test your code thoroughly (at least to see the new case is noticed).

Of course if a particular switch would be used more than one places, it's cut out into a function (don't repeat yourself).

If you want to extend these switches just do a grep 'case[ ]*T_BAR' rn . (on Linux) and it will spit out the locations worth looking at. Since you need to look at the code, you will see some context which helps you how to add the new case correctly. When you use polymorphism the call sites are hidden inside the system, and you depend on the correctness of the documentation, if it exists at all.

Extending switches does not break the OCP too, since you does not alter the existing cases, just add a new case.

Switches also help the next guy trying to get accustomed to and understand the code:

• The possible cases are before your eyes. That's a good thing when reading code (less jumping around).
• But virtual method calls are just like normal method calls. One can never know if a call is virtual or normal (without looking up the class). That's bad.
• But if the call is virtual, possible cases are not obvious (without finding all derived classes). That's also bad.

When you provide an interface to a thirdparty, so they can add behavior and user data to a system, then that's a different matter. (They can set callbacks and pointers to user-data, and you give them handles)

Further debate can be found here: http://c2.com/cgi/wiki?SwitchStatementsSmell

I'm afraid my "C-hacker's syndrome" and anti-OOPism will eventually burn all my reputation here. But whenever I needed or had to hack or bolt something into a procedural C system, I found it quite easy, the lack of constraints, forced encapsulation and less abstraction layers makes me "just do it". But in a C++/C#/Java system where tens of abstraction layers stacked on the top of each other in the software's lifetime, I need to spend many hours sometimes days to find out how to correctly work around all the constraints and limitations that other programmers built into their system to avoid others "messing with their class".