本文原文连接：http://blog.csdn.net/bluishglc/article/details/12652379 转载请注明出处！
如果你是一个有着深刻OO背景的程序员,你必定已经习惯于使用OO的思维进行分析和建模，从领域问题中去抽象概念，形成你的“对象”。如果业务系统中有一组相似却彼此存在差异的概念，你抽象出的往往是一个类族(Class Hierarchy) 。如果它们共同具有的业务方法因各自的特点而在处理行为上表现出差异,那此时就是展现"多态"魅力的最佳时机.
"多态"是实现"基于抽象编程"的重要保障机制,它让程序远离了大量令人懊恼的if...else...,使代码变得优雅简洁,在引入新的类型时也不需要对现有类型做任何修改(保证了"开闭原则"）,种种这些好处确实让人激动!但是如果你仔细回顾那些自己曾经所设计过的类族,可能是你没有意识到,可能你也曾经困惑过,那就是在你四处自由而愉快地使用着你的接口或是抽象基类写程序而不必在乎当下是哪个具体类的时候，在你程序的某个地方,你却无论如何也不能直接使用你的那个接口或是抽象基类了，在那个点上，原本看似完美的类族被彻底地“打回了原形”，因为你意识到你将不得不一一判断当前对象是哪一种具体类了。可能你会不甘心，用怀疑的眼光重新审视你的类族, 尝试找出设计上的失误，让这最后一处"异类"能纳入"大同",然而几经改动,最初的方案可能都已经被过度设计了,而你还是没有找到解决方法，于是你无可奈何，最后还是老老实实地使用了一连串的if...else...
是什么原因导致了这种情况的发生？是设计上的瑕疵还是“多态”天生的缺陷？回到那个让你头疼的“点”上，看看你的代码正在做什么？是不是正在从外部输入：一个UI，一个命令行，或是数据库中构建你的类族？或是反过来正将你的类族展示到UI、命令行或是持久化到数据库中？或者更为抽象但准确地说，你正在试图将一个结点“类型化”的“树”状数据结构向结点“无类型区分”的“扁平”数据结构进行转化（或反过来），以达到展示或是储存的目的？如果是这样，那就不用再纠结，这个“点”是你不可能规避的，你实际上正处在一个从OO模型向非OO模型（或反之）转化的"边界"上，在非OO模型那一则，没有叫"多态"的东西，所以，按照每个对象的具体类型，通过一连串的if...else...去完成这种转化是正常且不可避免的。
如果你能再深入地思考下去，你会找到这个问题最底层的原因，这个原因深刻但足以让你信服而不再纠缠这个问题，这个原因就是OO中的那个“老问题”：阻抗失配（Impedance Mismatch）！