比如，Derivate继承自Base，有个虚函数fun()。
Base A; Derivate B,C;
A *a;
Switch(ConditionPara)
{
case ConditonA:
a = new A;
case ConditionB:
a = new B;
break;
case ConditionC:
a = new C;
break;
}
a->fun();
上述代码感觉跟不用多态的功能差不多啊。
Base A; Derivate B,C;
Switch(ConditionPara)
{
case ConditonA:
A a;
a.fun()
break;
case ConditionB:
B b;
b.fun()
break;
case ConditionC:
C c;
c.fun();
break;
}
感觉上述两个实现都差不多啊。而且，第二种看起来更直接，多态的优势在哪里啊？？？？？
------解决方案--------------------------------------------------------
如果一上来就拿出A类型、B类型这类不“自然”的代码示例，或者像有些人那样为了复用一些代码而奢谈继承和多态，“为了继承而继承，为了多态而多态”，过于技术化，就会进入设计误区。
继承和多态，生活中的例子无处不在，每一分钟你想到事物概念时都自觉不自觉地应用着。中国古代的逻辑史上有一个著名的“白马非马”的谬论，公孙龙牵马要过城门，守门士兵说有规定马不让过关，公孙龙大言不惭地说“我牵的是白马，不是马”。这就好像说你写的处理“员工”的程序，对于实例化为“员工”的对象允许安排培训，对于实例化为“机关干部”的就不允许了，你说“我这个功能只对员工服务，不对机关干部”服务，这样客户一定会觉得你的脑子因为搞软件开发而变傻了（其实搞OO设计的人应该理解力更强、更灵活才对）！
如果你的编程语言可以让你清晰直观地这样表达代码逻辑，就是OOPL语言。否则，你的编程语言就限制了你的表达能力，你只能用编程语言可以支持运行的很低级的方式模拟表达这种能力。
多态是所有OOPL的基本特征。
------解决方案--------------------------------------------------------
软件开发中有一个原则叫做：开放封闭原则（OCP）
意思是对 追加功能开发，对修改功能封闭
回到你的问题上：
用多态的方案，你可以在不修改原来代码的情况下追加新的类。以扩从系统功能。
而如果用分支，每增加一个分支，你都需要对现有的程序进行修改，测试。
特别是当这个分支遍布你的软件很多地方的时候，情况更糟糕！