代码设计模式 【转载】面向对象编程的弊端是什么？(4)

正是这种累赘和虚假的承诺的拖累，而不是为了应付“需求改变”所必需的“灵活性”，才是大多数面向对象项目代码量暴增的元凶。

2、没有真正的抓到一类事物（在当前应用场景下）的根本，就去设计继承结构，是必不会有所得的。

不仅如此，请注意我强调了在当前应用场景下。

这是因为，分类是一个极其主观的东西，不存在普适的分类法。

举例来说，我要研究种族歧视，那么必然以肤色分类；换到法医学，那就按死因分类；生物学呢，则搞门科目属种……

想象下，需求是“时尚女装”，你却按“窒息死亡/溺水死亡/中毒死亡之体征”来了个分类……你说后面这软件还能写吗？

类似的，我遇到过写游戏的却去纠结“武器装备该不该从游戏角色继承”的神人。你觉得呢？

事实上，游戏界真正的抽象方法之一是：一切都是个有位置能感受时间流逝的精灵；而某个“感受到时间流逝显示不同图片的对象”，其实就是游戏主角；而“当收到碰撞事件时，改变主角下一轮显示的图片组的”，就是游戏逻辑。

看看它和“武器装备该不该从游戏角色继承”能差多远。想想到得后来，以游戏角色为基类的方案会变成什么样子？为什么会这样？

最具重量级的则是：正方形是不是一个矩形？它该不该从矩形继承？如果可以从矩形继承，那么什么是正方形的长和宽？在这个设计里，如果我修改了正方形的长，那么这个正方形类还能不能叫正方形？它不应该自然转换成长方形吗？如果我有两个List，一个存长方形，一个存正方形，自动转换后的对象能否自动迁移到合适的list？什么语言能提供这种机制？如果不能，“一视同仁的处理某个容器中的所有元素”岂不变成了一句屁话？

造成这颗的根本原因是，面向对象中的“类”，和我们日常语言乃至数学语言中的“类”根本就不是一码事。

面向对象中的“类”，意思是“接口上兼容的一系列对象”，关注的只不过是接口的兼容性而已（可搜索 里氏代换）；关键放在“可一视同仁的处理”上（学术上叫is-a）。

显然，这个定义完全是且只是为了应付归一化的需要。

这个定义经常和我们日常对话中提到的类概念上重合；但，如前所述，根本上却彻彻底底是八杆子打不着的两码事。

就着生活经验滥用“类”这个术语，甚至依靠这种粗浅认识去做设计，必然会导致出现各种各样的偏差。这种设计实质上就是在胡说八道。

就着这种胡说八道来写程序——有人觉得这种人能有好结果吗？

——但，几乎所有的面向对象语言、差不多所有的面向对象方法论，却就是在鼓励大家都这么做，完全没有意识到它们的理论基础有多么的不牢靠。

——如此作死，焉能不死？！

——你还敢说面向对象无害吗？

——在真正明白何谓封装、何谓归一化之前，每一次写下class，就在错误的道路上又多走了一步。

——设计真正需要关注的核心其实很简单，就是封装和归一化。一个项目开始的时候，“class”写的越早，就离这个核心越远。

——过去鼓吹的各种面向对象方法论、甚至某些语言本身，恰恰正是在怂恿甚至逼迫开发者尽可能早、尽可能多的写class。

重复一遍：封装可（通过固定接口而）应付需求变更、归一化可简化（类的使用者的）设计：以上，就是面向对象最最基本的好处。

——其它一切，都不过是在这两个基础上的衍生而已。

换言之，如果得不到这两个基本好处，那么也就没有任何衍生好处——应付需求变更/简化设计并不是打打嘴炮就能做到的。

误解四、只有面向对象语言写的程序才是面向对象的。

事实上，unix系统提出泛文件概念时，面向对象语言根本就不存在；游戏界的精灵这个基础抽象，最初是用C甚至汇编写的；……。

面向对象其实是汲取以上各种成功设计的经验才提出来的。

所以，面向对象的设计，不必非要c++/java之类支持面向对象的语言才能实现；它们不过是在你做出了面向对象的设计之后，能让你写得更惬意一些罢了——但，如果一个项目无需或无法做出面向对象的设计，某些面向对象语言反而会让你很难受。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-85281-4.html