Calmarius :
Switches and polymorphism does the same thing. \n\nIn 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.\n\nSo if your interface is fixed and you only add new types, polymorphism is your friend. \nBut if you add new functions to your interface you will need to update all implementations.\n\nIn 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.\n\nWith 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.\n\nSince pro-polymorphism points are well discussed here, let me provide a pro-switch point.\n\nOOP 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.\n\nSwitches can be done right:\n\nswitch (type)\n{\n case T_FOO: doFoo(); break;\n case T_BAR: doBar(); break;\n default:\n fprintf(stderr, \"You, who are reading this, add a new case for %d to the FooBar function ASAP!\\n\", type);\n assert(0);\n}\n\n\nThis 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). \n\nOf course if a particular switch would be used more than one places, it's cut out into a function (don't repeat yourself).\n\nIf 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.\n\nExtending switches does not break the OCP too, since you does not alter the existing cases, just add a new case.\n\nSwitches also help the next guy trying to get accustomed to and understand the code: \n\n\nThe possible cases are before your eyes. That's a good thing when reading code (less jumping around).\nBut 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.\nBut if the call is virtual, possible cases are not obvious (without finding all derived classes). That's also bad.\n\n\nWhen 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)\n\nFurther debate can be found here: http://c2.com/cgi/wiki?SwitchStatementsSmell\n\nI'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\".",
2013-03-13T15:17:07
Nick Fortescue :
This is mainly to do with encapsulation of knowledge. Let's start with a really obvious example - toString(). This is Java, but easily transfers to C++. Suppose you want to print a human friendly version of an object for debugging purposes. You could do:\n\nswitch(obj.type): {\ncase 1: cout << \"Type 1\" << obj.foo <<...; break; \ncase 2: cout << \"Type 2\" << ...\n\n\nThis would however clearly be silly. Why should one method somewhere know how to print everything. It will often be better for the object itself to know how to print itself, eg:\n\ncout << object.toString();\n\n\nThat way the toString() can access member fields without needing casts. They can be tested independently. They can be changed easily.\n\nYou could argue however, that how an object prints shouldn't be associated with an object, it should be associated with the print method. In this case, another design pattern comes in helpful, which is the Visitor pattern, used to fake Double Dispatch. Describing it fully is too long for this answer, but you can read a good description here.",
2008-10-24T17:39:45
patros :
It works very well if you understand it.\n\nThere are also 2 flavors of polymorphism. The first is very easy to understand in java-esque:\n\ninterface A{\n\n int foo();\n\n}\n\nfinal class B implements A{\n\n int foo(){ print(\"B\"); }\n\n}\n\nfinal class C implements A{\n\n int foo(){ print(\"C\"); }\n\n}\n\n\nB and C share a common interface. B and C in this case can't be extended, so you're always sure which foo() you're calling. Same goes for C++, just make A::foo pure virtual.\n\nSecond, and trickier is run-time polymorphism. It doesn't look too bad in pseudo-code.\n\nclass A{\n\n int foo(){print(\"A\");}\n\n}\n\nclass B extends A{\n\n int foo(){print(\"B\");}\n\n}\n\nclass C extends B{\n\n int foo(){print(\"C\");}\n\n}\n\n...\n\nclass Z extends Y{\n\n int foo(){print(\"Z\");\n\n}\n\nmain(){\n\n F* f = new Z();\n A* a = f;\n a->foo();\n f->foo();\n\n}\n\n\nBut it is a lot trickier. Especially if you're working in C++ where some of the foo declarations may be virtual, and some of the inheritance might be virtual. Also the answer to this:\n\nA* a = new Z;\nA a2 = *a;\na->foo();\na2.foo();\n\n\nmight not be what you expect.\n\nJust keep keenly aware of what you do and don't know if you're using run-time polymorphism. Don't get overconfident, and if you're not sure what something is going to do at run-time, then test it.",
2008-10-24T18:23:27
paercebal :
Do not fear...\nI guess your problem lies with familiarity, not technology. Familiarize yourself with C++ OOP.\nC++ is an OOP language\nAmong its multiple paradigms, it has OOP features and is more than able to support comparison with most pure OO language.\nDon't let the "C part inside C++" make you believe C++ can't deal with other paradigms. C++ can handle a lot of programming paradigms quite graciously. And among them, OOP C++ is the most mature of C++ paradigms after procedural paradigm (i.e. the aforementioned "C part").\nPolymorphism is Ok for production\nThere is no "subtle bugs" or "not suitable for production code" thing. There are developers who remain set in their ways, and developers who'll learn how to use tools and use the best tools for each task.\nswitch and polymorphism are [almost] similar...\n... But polymorphism removed most errors.\nThe difference is that you must handle the switches manually, whereas polymorphism is more natural, once you get used with inheritance method overriding.\nWith switches, you'll have to compare a type variable with different types, and handle the differences. With polymorphism, the variable itself knows how to behave. You only have to organize the variables in logical ways, and override the right methods.\nBut in the end, if you forget to handle a case in switch, the compiler won't tell you, whereas you'll be told if you derive from a class without overriding its pure virtual methods. Thus most switch-errors are avoided.\nAll in all, the two features are about making choices. But Polymorphism enable you to make more complex and in the same time more natural and thus easier choices.\nAvoid using RTTI to find an object's type\nRTTI is an interesting concept, and can be useful. But most of the time (i.e. 95% of the time), method overriding and inheritance will be more than enough, and most of your code should not even know the exact type of the object handled, but trust it to do the right thing.\nIf you use RTTI as a glorified switch, you're missing the point.\n(Disclaimer: I am a great fan of the RTTI concept and of dynamic_casts. But one must use the right tool for the task at hand, and most of the time RTTI is used as a glorified switch, which is wrong)\nCompare dynamic vs. static polymorphism\nIf your code does not know the exact type of an object at compile time, then use dynamic polymorphism (i.e. classic inheritance, virtual methods overriding, etc.)\nIf your code knows the type at compile time, then perhaps you could use static polymorphism, i.e. the CRTP pattern http://en.wikipedia.org/wiki/Curiously_Recurring_Template_Pattern\nThe CRTP will enable you to have code that smells like dynamic polymorphism, but whose every method call will be resolved statically, which is ideal for some very critical code.\nProduction code example\nA code similar to this one (from memory) is used on production.\nThe easier solution revolved around a the procedure called by message loop (a WinProc in Win32, but I wrote a simplier version, for simplicity's sake). So summarize, it was something like:\nvoid MyProcedure(int p_iCommand, void *p_vParam)\n{\n // A LOT OF CODE ???\n // each case has a lot of code, with both similarities\n // and differences, and of course, casting p_vParam\n // into something, depending on hoping no one\n // did a mistake, associating the wrong command with\n // the wrong data type in p_vParam\n\n switch(p_iCommand)\n {\n case COMMAND_AAA: { /* A LOT OF CODE (see above) */ } break ;\n case COMMAND_BBB: { /* A LOT OF CODE (see above) */ } break ;\n // etc.\n case COMMAND_XXX: { /* A LOT OF CODE (see above) */ } break ;\n case COMMAND_ZZZ: { /* A LOT OF CODE (see above) */ } break ;\n default: { /* call default procedure */} break ;\n }\n}\n\nEach addition of command added a case.\nThe problem is that some commands where similar, and shared partly their implementation.\nSo mixing the cases was a risk for evolution.\nI resolved the problem by using the Command pattern, that is, creating a base Command object, with one process() method.\nSo I re-wrote the message procedure, minimizing the dangerous code (i.e. playing with void *, etc.) to a minimum, and wrote it to be sure I would never need to touch it again:\nvoid MyProcedure(int p_iCommand, void *p_vParam)\n{\n switch(p_iCommand)\n {\n // Only one case. Isn't it cool?\n case COMMAND:\n {\n Command * c = static_cast<Command *>(p_vParam) ;\n c->process() ;\n }\n break ;\n default: { /* call default procedure */} break ;\n }\n}\n\nAnd then, for each possible command, instead of adding code in the procedure, and mixing (or worse, copy/pasting) the code from similar commands, I created a new command, and derived it either from the Command object, or one of its derived objects:\nThis led to the hierarchy (represented as a tree):\n[+] Command\n |\n +--[+] CommandServer\n | |\n | +--[+] CommandServerInitialize\n | |\n | +--[+] CommandServerInsert\n | |\n | +--[+] CommandServerUpdate\n | |\n | +--[+] CommandServerDelete\n |\n +--[+] CommandAction\n | |\n | +--[+] CommandActionStart\n | |\n | +--[+] CommandActionPause\n | |\n | +--[+] CommandActionEnd\n |\n +--[+] CommandMessage\n\nNow, all I needed to do was to override process for each object.\nSimple, and easy to extend.\nFor example, say the CommandAction was supposed to do its process in three phases: "before", "while" and "after". Its code would be something like:\nclass CommandAction : public Command\n{\n // etc.\n virtual void process() // overriding Command::process pure virtual method\n {\n this->processBefore() ;\n this->processWhile() ;\n this->processAfter() ;\n }\n\n virtual void processBefore() = 0 ; // To be overriden\n \n virtual void processWhile()\n {\n // Do something common for all CommandAction objects\n }\n \n virtual void processAfter() = 0 ; // To be overriden\n\n} ;\n\nAnd, for example, CommandActionStart could be coded as:\nclass CommandActionStart : public CommandAction\n{\n // etc.\n virtual void processBefore()\n {\n // Do something common for all CommandActionStart objects\n }\n\n virtual void processAfter()\n {\n // Do something common for all CommandActionStart objects\n }\n} ;\n\nAs I said: Easy to understand (if commented properly), and very easy to extend.\nThe switch is reduced to its bare minimum (i.e. if-like, because we still needed to delegate Windows commands to Windows default procedure), and no need for RTTI (or worse, in-house RTTI).\nThe same code inside a switch would be quite amusing, I guess (if only judging by the amount of "historical" code I saw in our app at work).",
2008-10-24T19:48:49
Vincent Ramdhanie :
Unit testing an OO program means testing each class as a unit. A principle that you want to learn is \"Open to extension, closed to modification\". I got that from Head First Design Patterns. But it basically says that you want to have the ability to easily extend your code without modifying existing tested code.\n\nPolymorphism makes this possible by eliminating those conditional statements. Consider this example:\n\nSuppose you have a Character object that carries a Weapon. You can write an attack method like this:\n\nIf (weapon is a rifle) then //Code to attack with rifle else\nIf (weapon is a plasma gun) //Then code to attack with plasma gun\n\n\netc.\n\nWith polymorphism the Character does not have to \"know\" the type of weapon, simply \n\nweapon.attack()\n\n\nwould work. What happens if a new weapon was invented? Without polymorphism you will have to modify your conditional statement. With polymorphism you will have to add a new class and leave the tested Character class alone.",
2008-10-24T17:33:11
rice :
I'm a bit of a skeptic: I believe inheritance often adds more complexity than it removes.\n\nI think you are asking a good question, though, and one thing I consider is this:\n\nAre you splitting into multiple classes because you are dealing with different things? Or is it really the same thing, acting in a different way?\n\nIf it's really a new type, then go ahead and create a new class. But if it's just an option, I generally keep it in the same class.\n\nI believe the default solution is the single-class one, and the onus is on the programmer proposing inheritance to prove their case.",
2008-10-24T17:56:33
JohnMcG :
Not an expert in the implications for test cases, but from a software development perspective:\n\n\nOpen-closed principle -- Classes should be closed to alteration, but open to extension. If you manage conditional operations via a conditional construct, then if a new condition is added, your class needs to change. If you use polymorphism, the base class need not change.\nDon't repeat yourself -- An important part of the guideline is the \"same if condition.\" That indicates that your class has some distinct modes of operation that can be factored into a class. Then, that condition appears in one place in your code -- when you instantiate the object for that mode. And again, if a new one comes along, you only need to change one piece of code.\n",
2008-10-24T17:33:40
QBziZ :
Polymorphism is one of the corner stones of OO and certainly is very useful.\nBy dividing concerns over multiple classes you create isolated and testable units.\nSo instead of doing a switch...case where you call methods on several different types or implemenations you create a unified interface, having multiple implementations. \nWhen you need to add an implementation, you do not need to modify the clients, as is the case with switch...case. Very important as this helps to avoid regression.\n\nYou can also simplify your client algorithm by dealing with just one type : the interface.\n\nVery important to me is that polymorphism is best used with a pure interface/implementation pattern ( like the venerable Shape <- Circle etc... ) . \nYou can also have polymorphism in concrete classes with template-methods ( aka hooks ), but its effectiveness decreases as complexity increases.\n\nPolymorphism is the foundation on which our company's codebase is built, so I consider it very practical.",
2008-10-24T17:32:45