浅谈面向对象的坏处

1、性能。

现时C++可以说是支持OOP范式中最为常用及高性能的语言。虽然如此，在C++使用OOP的编程方式在一些场合未能提供最高性能。 [1]详细描述了这个观点，我在此尝试简单说明。注意：其他支持OOP的语言通常都会有本答案中提及的问题，C++只是一个合适的说明例子。

历史上，OOP大概是60年代出现，而C++诞生于70年代末。现在的硬件和当时的有很大差异，其中最大的问题是内存墙_百度百科。

<img src="https://pic3.zhimg.com/9cd401779cb4e34813d38b38c479696a_b.jpg" data-rawwidth="733" data-rawheight="399" class="origin_image zh-lightbox-thumb" width="733" data-original="https://pic3.zhimg.com/9cd401779cb4e34813d38b38c479696a_r.jpg">图1: 处理器和内存的性能提升比较，处理器的提升速度大幅高于内存[2]。图1: 处理器和内存的性能提升比较，处理器的提升速度大幅高于内存[2]。

跟据Numbers Every Programmer Should Know By Year：
<img src="https://pic1.zhimg.com/6c35a1ff4d77a59f9ff41d276d97c3d8_b.jpg" data-rawwidth="553" data-rawheight="276" class="origin_image zh-lightbox-thumb" width="553" data-original="https://pic1.zhimg.com/6c35a1ff4d77a59f9ff41d276d97c3d8_r.jpg">图2：2014年计算机几种操作的潜伏期（latency）。图2：2014年计算机几种操作的潜伏期（latency）。

从这些数据，我们可以看出，内存存取成为现代计算机性能的重要瓶颈。然而，这个问题在C++设计OOP编程范式的实现方式之初应该并未能考虑得到。现时的OOP编程有可能不缓存友好（cache friendly），导致有时候并不能发挥硬件最佳性能。以下描述一些箇中原因。

1. 过度封装

使用OOP时，会把一些复杂的问题分拆抽象成较简单的独立对象，通过对象的互相调用去实现方案。但是，由于对象包含自己封装的数据，一个问题的数据集会被分散在不同的内存区域。互相调用时很可能会出现数据的cache miss的情况。

2. 多态

在C++的一般的多态实现中，会使用到虚函数表。虚函数表是通过加入一次间接层来实现动态派送。但在调用的时候需要读取虚函数表，增加cache miss的可能性。基本上要支持动态派送，无论用虚函数表、函数指针都会形成这个问题，但如果类的数目极多，把函数指针如果和数据放在一起有时候可放缓问题。

3. 数据布局

虽然OOP本身并无限制数据的布局方式，但基本上绝大部分OOP语言都是把成员变量连续包裹在一段内存中。甚至使用C去编程的时候，也通常会使用到OOP或Object-based的思考方式，把一些相关的数据放置于一个struct之内：

struct Particle {    Vector3 position;    Vector4 velocity;    Vector4 color;    float age;    // ...};

即使不使用多态，我们几乎不加思索地会使用这种数据布局方式。我们通常会以为，由于各个成员变量都紧凑地放置在一起，这种数据布局通常对缓存友好。然而，实际上，我们需要考虑数据的存取模式（access pattern）。

在OOP中，通过封装，一个类的各种功能会被实现为多个成员函数，而每个成员函数实际上可能只会存取少量的成员变量。这可能形式非常严重的问题，例如：

for (Particle* p = begin; p != end; ++p)    p->position += p->velocity * dt; // 或 p->SimulateMotion(dt);

在这种模式下，实阶上只存取了两个成员变量，但其他成员变量也会载入缓存造成浪费。当然，如果在迭代的时候能存取尽量多的成员变量，这个问题可能并不存在，但实际上是很困难的。

如果采用传统的OOP编程范式及实现方式，数据布局的问题几乎没有解决方案。所以在[1]里，作者提出，在某些情况下，应该放弃OOP方式，以数据的存取及布局为编程的考虑重中，称作面向数据编程（data-oriented programming, DOP）。

有关DOP的内容就不在此展开了，读者可参考[1]，还有[3]作为实际应用例子。

[1] ALBRECHT, “Pitfalls of Object Oriented Programming”, GCAP Australia, 2009. http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf
[2] Hennessy, John L., and David A. Patterson. Computer architecture: a quantitative approach. Elsevier, 2012.
[3] COLLIN, “Culling the Battlefield”, GDC 2011. http://dice.se/wp-content/uploads/CullingTheBattlefield.pdf

2  

- 降低可读性
- 维护高度模块化的工程刚开始阅读就是噩梦，设计和可阅读性、时间空间一直都是一对阴阳组合

但是OOP最重要的目标，其实是OCP，即「开闭原则」。这一点很多答案都没有提到。

遵循开闭原则设计出的模块具有两个主要特征：
（1）对于扩展是开放的（Open for extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，我们可以改变模块的功能。
（2）对于修改是关闭的（Closed for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者.EXE文件，都无需改动。

这就是为什么会有「用多态代替switch」的说法。在应该使用多态的地方使用switch，会导致：

1 - 违反「开放扩展」原则。假如别人的switch调用了你的代码，你的代码要扩展，就必须在别人的代码里，人工找出每一个调用你代码的switch，然后把你新的case加进去。
2 - 违反「封闭修改」原则。这是说，被switch调用的逻辑可能会因为过于紧密的耦合，而无法在不碰switch的情况下进行修改。

但是OCP不是免费的。如果一个模块根本没有扩展的需求，没有多人协作的需求，花时间达成OCP又有什么意义呢？设计类关系的时候忘记了OOP的初心，可能就会写出很多没有帮助的类，白白浪费人力和运行效率。

所以，假如所有代码都是你一个人维护，没有什么扩展的需求，那么多用一些switch也未尝不可；假如你的代码是要被别人使用或者使用了别人的代码，OOP很可能就是你需要用到的工具。

除了OOP，Type class和Duck Typing都是可以帮助你达成OCP原则的工具。当然，如果你使用的语言是Java，这两种工具都不用想了。

3   

没有人还记得面向对象原本要解决的问题是什么。

1、面向对象原本要解决什么（或者说有什么优良特性）
似乎很简单，但实际又很不简单：面向对象三要素封装、继承、多态

（警告：事实上，从业界如此总结出这面向对象三要素的一刹那开始，就已经开始犯错了！）。

封装：封装的意义，在于明确标识出允许外部使用的所有成员函数和数据项，或者叫接口。

有了封装，就可以明确区分内外，使得类实现者可以修改封装内的东西而不影响外部调用者；而外部调用者也可以知道自己不可以碰哪里。这就提供一个良好的合作基础——或者说，只要接口这个基础约定不变，则代码改变不足为虑。



继承+多态：继承和多态必须一起说。一旦割裂，就说明理解上已经误入歧途了。

先说继承：继承同时具有两种含义：其一是继承基类的方法，并做出自己的改变和/或扩展——号称解决了代码重用问题；其二是声明某个子类兼容于某基类（或者说，接口上完全兼容于基类），外部调用者可无需关注其差别（内部机制会自动把请求派发[dispatch]到合适的逻辑）。

再说多态：基于对象所属类的不同，外部对同一个方法的调用，实际执行的逻辑不同。

很显然，多态实际上是依附于继承的两种含义的：“改变”和“扩展”本身就意味着必须有机制去自动选用你改变/扩展过的版本，故无多态，则两种含义就不可能实现。

所以，多态实质上是继承的实现细节；那么让多态与封装、继承这两个概念并列，显然是不符合逻辑的。不假思索的就把它们当作可并列概念使用的人，显然是从一开始就被误导了——正是这种误导，使得大多数人把注意力过多集中在多态这个战术层面的问题上，甚至达到近乎恶意利用的程度；同时却忽略了战略层面的问题，这就致使软件很容易被他们设计成一滩稀屎（后面会详细谈论这个）。


实践中，继承的第一种含义（实现继承）意义并不很大，甚至常常是有害的。因为它使得子类与基类出现强耦合。

继承的第二种含义非常重要。它又叫“接口继承”。
接口继承实质上是要求“做出一个良好的抽象，这个抽象规定了一个兼容接口，使得外部调用者无需关心具体细节，可一视同仁的处理实现了特定接口的所有对象”——这在程序设计上，叫做归一化。


归一化使得高层的外部使用者可以不加区分的处理所有接口兼容的对象集合——就好象linux的泛文件概念一样，所有东西都可以当文件处理，不必关心它是内存、磁盘、网络还是屏幕（当然，对底层设计者，当然也可以区分出“字符设备”和“块设备”，然后做出针对性的设计：细致到什么程度，视需求而定）。

归一化的实例：
a、一切对象都可以序列化/toString
b、一切UI对象都是个window，都可以响应窗口事件。

——必须注意，是一切（符合xx条件的）对象皆可以做什么，而不是“一切皆对象”。后者毫无意义（从信息论角度上说，一切皆xx蕴含的信息量为0）。


显然，归一化可以大大简化使用者的处理逻辑：
这和带兵打仗是类似的，班长需要知道每个战士的姓名/性格/特长，否则就不知道该派谁去对付对面山坡上的狙击手；而连长呢，只需知道自己手下哪个班/排擅长什么就行了，然后安排他们各自去守一段战线；到了师长/军长那里，他更关注战场形势的转变及预期……没有这种层层简化、而是必须直接指挥到每个人的话，累死军长都没法指挥哪怕只是一场形势明朗的冲突——光一个个打完电话就能把他累成哑巴。

反过来也对：军长压根就不应该去干涉某个步兵班里、几个大头兵之间的战术配合；这不仅耽误他行使身为军长的职责，也会干扰士兵们长久以来养成的默契。他的职责是让合适的部队在合适的时机出现在合适的战场，而不是一天到晚对着几个小兵指手画脚、弄的他们无所适从。

约束各单位履行各自的职责、禁止它们越级胡乱指挥，这就是封装。

正是通过封装和归一化，我们才可以做到“如果一个师解决不了问题，那就再调两个师”“如果单凭陆军解决不了问题，那就让空军也过来”——这种灵活性显然是从良好的部队编制得来的。在软件设计里，我们叫它“通过合理模块化而灵活应对需求变更”。



软件设计同样。比如说，消息循环在派发消息时，只需知道所有UI对象都是个window，都可以响应窗口消息就足够了；它没必要知道每个UI对象究竟是什么（归一化）、也不应该关心这个UI对象的内部执行细节（封装）——该对象自己知道收到消息该怎么做；而且若它出了问题，只需修改该对象即可，不会影响外部。

合理划分功能层级、适时砍掉不必要的繁杂信息，一层层向上提供简洁却又完备的信息/接口，高层模块才不会被累死——KISS是最难也是最优的软件设计方法，没有之一。


可见，封装和归一化才是战略层面、生死攸关的问题。遵循它并不能保证你一定能打胜仗，但违反它你必定死的很难看。

但这两个问题太大、太难，并且不存在普适性答案。这就使得没有足够经验、缺乏认真思考的外行们根本无从置喙。



前面提到过，人们错误的把多态这个战术技巧提到“封装和归一化”相同的战略层面上。这就致使本该谈论战略的设计工作被一群毫无实践经验、只会就着浅显的多态胡扯八道的战术家攻占和把持，进而使得“以战术代替战略”成为普遍现象——因为对他们来说，多态是既容易理解又容易玩出诸多花样的；而封装和归一化就太空泛又太复杂，对他们来说完全无从着手了。
所以，他们把一切精力都用在多态的滥用上，却从不谈封装和归一化：即使谈到了，也是作为多态的附庸出现的。

这种战术层面的空谈很容易、也很容易出彩，但并不解决问题——反而总是导致简单问题复杂化。
然而，对于如何解决问题，他们并不在行，也不在乎。因为他们没有能力在乎。
这就要命了。



总结：面向对象的好处实际就这么两点。
一是通过封装明确定义了何谓接口、何谓接口内部实现、何谓接口的外部调用者，使得大家各司其职，不得越界；
二是通过继承+多态这种内置机制，在语言的层面支持归一化的设计，并使得内行可以从代码本身看到这个设计——但，注意仅仅只是支持归一化的设计。不懂如何做出这种设计的外行仍然不可能从瞎胡闹的设计中得到任何好处。


显然，不用面向对象语言、不用class，一样可以做归一化的设计（如老掉牙的泛文件概念、游戏行业的一切皆精灵），一样可以封装（通过定义模块和接口），只是用面向对象语言可以直接用语言元素显式声明这些而已；
而用了面向对象语言，满篇都是class，并不等于就有了归一化的设计。甚至，因为被这些花哨的东西迷惑，反而更加不知道什么才是设计。


2、人们以为面向对象是什么、以及因此制造出的悲剧以及闹剧

误解一、面向对象语言支持用语言元素直接声明封装性和接口兼容性，所以用面向对象语言写出来的东西一定更清晰、易懂。

事实上，既然class意味着声明了封装、继承意味着声明了接口兼容，那么错误的类设计显然就是错误的声明、盲目定义的类就是无意义的喋喋不休。而错误的声明比没有声明更糟；通篇毫无意义的喋喋不休还不如错误的声明。

除非你真正做出了漂亮的设计，然后用面向对象的语法把这个设计声明出来——仅仅声明真正有设计、真正需要人们注意的地方，而不是到处瞎叫唤——否则不可能得到任何好处。

一切皆对象实质上是在鼓励堆砌毫无意义的喋喋不休，并且用这种战术层面都蠢的要命的喋喋不休来代替战略层面的考量。

大部分人——注意，不是个别人——甚至被这种无意义的喋喋不休搞出了神经质，以至于非要在喋喋不休中找出意义：没错，我说的就是设计模式驱动编程，以及如此理解面向对象编程。



误解二、面向对象三要素是封装、继承、多态，所以只要是面向对象语言写的程序，就一定“继承”了语言的这三个优良特性。

事实上，如前所述，封装、继承、多态只是语言层面对良好设计的支持，并不能导向良好的设计。
如果你的设计做不出真正的封装性、不懂得何谓归一化，那它用什么写出来都是垃圾（不仅如此，因为你的低水平，“面向对象三要素”反而会误导你，使你更快、更远、更诡异的偏离目标）。



误解三、把软件写成面向对象的至少是无害的。

要了解事实上是什么，需要先科普几个概念。


1、什么是真正的封装？

——回答我，封装是不是等于“把不想让别人看到、以后可能修改的东西用private隐藏起来”？

显然不是。
如果功能得不到满足、或者未曾预料到真正发生的需求变更，那么你怎么把一个成员变量/函数放到private里面的，将来就必须怎么把它挪出来。

你越瞎搞，越去搞某些华而不实的“灵活性”——比如某种设计模式——真正的需求来临时，你要动的地方就越多。

真正的封装是，经过深入的思考，做出良好的抽象，给出“完整且最小”的接口，并使得内部细节可以对外透明（注意：对外透明的意思是，外部调用者可以顺利的得到自己想要的任何功能，完全意识不到内部细节的存在；而不是外部调用者为了完成某个功能、却被碍手碍脚的private声明弄得火冒三丈；最终只能通过怪异、复杂甚至奇葩的机制，才能更改他必须关注的细节——而且这种访问往往被实现的如此复杂，以至于稍不注意就会酿成大祸）。

一个设计，只有达到了这个高度，才能真正做到所谓的“封装性”，才能真正杜绝对内部细节的访问。

否则，生硬放进private里面的东西，最后还得生硬的被拖出来——当然，这种东西经常会被美化成“访问函数”之类渣渣（不是说访问函数是渣渣，而是说因为设计不良、不得不以访问函数之类玩意儿在封装上到处挖洞洞这种行为是渣渣）。



一个典型的例子，就是C++的new和过于灵活的内存使用方式之间的耦合。
这个耦合就导致了new[]/delete[]、placement new/placement delete之类怪异的东西：这些东西必须成对使用，怎么分配就必须怎么释放，任何错误搭配都可能导致程序崩溃——这是为了兼容C、以及得到更高执行效率的无奈之举；但，它更是“抽象层次过于复杂，以至于无法做出真正透明的设计”的典型案例：只能说，c++设计者是真正的大师，如此复杂的东西在他手里，才仅仅付出了如此之小的代价。

(更准确点说，是new/delete和c++的其它语言元素之间是非正交的；于是当同时使用这些语言元素时，就不可避免的出现了彼此扯淡的现象。即new/delete这个操作对其它语言元素非透明：在c++的设计里，是通过把new/delete分成两层，一是内存分配、二是在分配的内存上初始化，然后暴露这个分层细节，从而在最大程度上实现了封装——但比之其它真正能彼此透明的语言元素间的关系，new/delete显然过于复杂了)

这个案例，可以非常直观的说明“设计出真正对外透明的封装”究竟会有多难。


2、接口继承真正的好处是什么？是用了继承就显得比较高大上吗？

显然不是。

接口继承没有任何好处。它只是声明某些对象在某些场景下，可以用归一化的方式处理而已。

换句话说，如果不存在“需要不加区分的处理类似的一系列对象”的场合，那么继承不过是在装X罢了。




了解了如上两点，那么，很显然：
1、如果你没有做出好的抽象、甚至完全不知道需要做好的抽象就忙着去“封装”，那么你只是在“封”和“装”而已。
这种“封”和“装”的行为只会制造累赘和虚假的承诺；这些累赘以及必然会变卦的承诺，必然会为未来的维护带来更多的麻烦，甚至拖垮整个项目。

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

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

不仅如此，请注意我强调了在当前应用场景下。
这是因为，分类是一个极其主观的东西，不存在普适的分类法。

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

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



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

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


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





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

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

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

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

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

就着生活经验滥用“类”这个术语，甚至依靠这种粗浅认识去做设计，必然会导致出现各种各样的偏差。这种设计实质上就是在胡说八道。
就着这种胡说八道来写程序——有人觉得这种人能有好结果吗？

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


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

——在真正明白何谓封装、何谓归一化之前，每一次写下class，就在错误的道路上又多走了一步。
——设计真正需要关注的核心其实很简单，就是封装和归一化。一个项目开始的时候，“class”写的越早，就离这个核心越远。
——过去鼓吹的各种面向对象方法论、甚至某些语言本身，恰恰正是在怂恿甚至逼迫开发者尽可能早、尽可能多的写class。


重复一遍：封装可（通过固定接口而）应付需求变更、归一化可简化（类的使用者的）设计：以上，就是面向对象最最基本的好处。
——其它一切，都不过是在这两个基础上的衍生而已。

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


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

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

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

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

用面向对象语言写程序，和一个程序的设计是面向对象的，两者是八杆子打不着的两码事。纯C写的linux kernel事实上比c++/java之类语言搞出来的大多数项目更加面向对象——只是绝大部分人都自以为自己到处瞎写class的面条代码才是面向对象的正统、而死脑筋的linus搞的泛文件抽象不过是过程式思维搞出来的老古董。

——这个误解之深，甚至达到连wiki词条里面，都把OOP定义为“用支持面向对象的语言写程序”的程度。
——我们提及面向对象时，明明在谈论战略、谈论软件总体设计；但总有人把它歪曲成战术方面的、漫无目标却还自我感觉良好的、琐碎的投机。
——恐怕这也是没有人说泛文件设计思想是个骗局、而面向对象却被业界大牛们严厉抨击的根本原因了：真正的封装、归一化精髓被抛弃，浮于表面的、喋喋不休的class/设计模式却成了”正统“！

借用楼下PeytonCai朋友的链接：
名家吐槽：面向对象编程从骨子里就有问题

————————————————————————————

总结： 面向对象其实是对过去成功的设计经验的总结。但那些成功的设计，不是因为用了封装/归一化而成功，而是切合自己面对的问题，给出了恰到好处的设计。

让一个初学者知道自己应该向封装/归一化这个方向前进，是好的；用一个面向对象的条条框框把他们框在里面、甚至使得他们以为写下class是完全无需思索的、真正应该追求的是设计模式，则是罪恶的——它实质上是把初学者的注意力从真正应该注意的封装、归一化方向引开，欺骗他们陷入“近乎恶意的全方位滥用多态”的泥潭。

事实上，class写的越随意，才越需要设计模式；就着错误的实现写得越多、特性用得越多，它就越发的死板，以至于必须更加多得多的特性、模式、甚至语法hack，才能勉强完成需求。

只有经过真正的深思熟虑，才有可能做到KISS。


到处鼓噪的面向对象编程的最大弊端，是把软件设计工作偷换概念，变成了“就着class及相关教条瞎胡闹，不管有没有好处先插一杠子”，甚至使得人们忘记去关注“抽象是否真正简化了面对的问题”——这是猥琐的投机，不是设计。

一言以蔽之：没有银弹。任何寄希望于靠着某种“高大上”的技术——无论是面向对象、数据驱动、消息驱动还是lambda、协程等等等等——就能一劳永逸的使得任何现实问题“迎刃而解”的企图都是注定要失败的，都不过是外行的意淫而已；靠意淫来做设计，不掉沟里才怪。

想要做出KISS的方案，就必须对面对的问题有透彻的了解，有足够的经验和能力，并经过深思熟虑，这才能做出简洁的抽象：至于最终的抽象是面向对象的、面向过程的还是数据驱动/消息驱动的，甚至是大杂烩的，那都无所谓。只要这个设计能做到最重要、也是最难的KISS，它就是个好设计。

在特定领域、特定场景下，的确有成功的经验、正确/合理的方向：技术无罪，但，没有银弹。


————————————————————————————————————————
2016.5.16：

嗯，这个是我很久很久以前在CU上发过的一系列帖子……

当时很多鼓吹“面向对象就是好来就是好的”就着一知半解胡搅蛮缠，这系列帖子是驳斥他们的。所以很多词句挖苦意味很浓，见谅。

再比如，传说中的面向对象本该大显神威的游戏领域——就说流行的WOW吧。

这个游戏有10个职业，10个种族，每个种族都有自己的几个特有种族天赋（这个种族天赋还可能根据职业有所不同，比如血精灵）；每个职业有几十甚至上百种不同的技能/法术，这些技能有近战技能，有远程技能；有的技能会对敌方造成伤害或不良状态，有的技能能给己方队友加上好的状态或治疗队友；而且很多这类技能还会根据目标的状态切换不同的效果；有些技能是单体效果，有些技能是光环效果（又分为对敌方造成光环效果还是对己方两种，也可能两者兼备），而另一些技能是地图范围效果（如烈焰风暴是一个圆形区域；冰锥术是一个锥形区域；特别的，顺劈斩是在当前攻击目标旁边不超过5码的另一个敌对目标——某个boss的顺劈斩更强，它会从第一个目标传递几十个目标，总传递距离可以达到夸张的几百码；并且这个伤害也是各有特色的：战士的顺劈斩是每个目标伤害固定，有些boss的则是同时挨打的人越多伤害越低，但还有个变态boss却是被打的人越多伤害越高……）；大多数技能还可以通过天赋雕文强化/改变的面目全非（比如插一个雕文，法师的火球就不会造成持续伤害但施法速度增加；点一个天赋，法师的冰冷减速效果就会降低对方受到的治疗效果；点某个天赋，盗贼的某些技能攻击就会延长自身提升攻击速度这个状态的持续时间，等等）；还有很多技能是因为学习了某个专业或装备/持有某个物品而得到（比如，学了采药，就可以得到生命之血这个技能，每3分钟可用，能够在若干秒内回复你若干生命值——这个技能和采药技能等级挂钩，但很可能接下来的某个版本，就会再和玩家的生命上限值挂钩，以避免它像现在一样，被玩家斥为废柴技能）；另外，不同等级的技能可能有施法时间甚至额外特效方面的差别；此外，每个技能会造成不同属性的伤害/效果（神圣、暗影、元素、物理等等），甚至一个技能同时造成多种类型伤害效果，更有冰火球这样根据目标抵抗力而智能选择更大杀伤效果类型的变态魔法……

最后，最最重要的是，这所有职业上千个技能（或许加上NPC特有的一些技能，数目会达到几千种）并不稳定，常常会因为某个技能或某些技能的组合过于强大/弱小而加以修改（比如加一个额外的负面状态如无敌/圣疗；甚至全面修改“抗性”“破甲”概念的定义）——玩过wow的都知道，这事几乎每个月都有发生。

好吧，你打算怎么设计这数千个技能/效果？
或者，你就这样把这些概念用class这个筐一装，然后到处开特例、特例都解决不了就搞23个模式使劲往一块粘，管他整体结构如何，淌哪算哪？

扯淡。


有个故事说的好：
有人送几个瞎子一条鱼，瞎子们高兴坏了，决定熬鱼汤喝。鱼汤熬好了，瞎子甲尝了一口，真鲜啊；瞎子乙赶紧也喝一口，太鲜了，太好喝了。几个瞎子一边喝一边赞美——忽然瞎子丙叫了起来：鱼跳我脚上了，它不在锅里！
众瞎子大惊：这鱼都没放到锅里，汤就鲜成这样了；要是放进锅里，还不得把我们都鲜死啊！

众面向对象原教旨主义者把事情搅得一团糟，同样也会大惊：天哪，用了面向对象都复杂成这样，这要不用面向对象，这软件就不能写了吧！

想想看，假如让那些面向对象原教旨主义者来设计，会出现什么情况：

定义一个基类叫技能；然后一个继承类叫法术技能，另一个叫物理技能；然后神圣法术从法术技能继承，疾病法术也从法术技能继承；由于圣骑士一个技能同时具备物理和法术两种效果，于是必须多重继承神圣法术和物理技能；多重继承太危险，于是不得不把神圣法术搞成接口类，引入接口继承甚至带实现的纯虚函数等等高端概念；然后，活该枪毙的暴雪设计师又想出了让某个技能同时对目标加上神圣持续伤害效果的奇怪点子——于是不得不再加个继承层次，使得神圣法术是神圣持续伤害法术的子集：仅立刻造成一次持续伤害的DOT（damage of time）技能……

那么，点一个天赋，一个技能就会有dot，否则就没有怎么办？

设计模式是灵丹妙药，不是吗 ^_^


等到把这所有几千个技能全部搞定，起码也是一个数万个类、几十层的恐怖继承树，并且会用完23个设计模式（甚至再发明几个新模式出来，我也不会感到奇怪），精巧复杂到没有任何人愿意去碰它。


但，请注意，天杀的暴雪设计师，在最开始的设计方案里规定DOT不能暴击；后来又添加约定说某某某职业的某个dot可以暴击；另一个职业的某个dot在点天赋后可暴击；至于死亡骑士，在他穿了T9套装中的其中四件装备时，他的某个瘟疫类型的dot可以暴击——但另一个瘟疫dot永远不能暴击。


嗯嗯嗯，太好解决了——这不就是策略模式吗？

好吧，你再填几十几百个类体系，然后把旧的几十层继承树中的数万个类一个个都策略化吧。反正不是我在维护……



哎呀不好，那个枪毙了几百次都还没死的暴雪设计师又出馊主意了，他要求：当死亡骑士点了邪恶系的某个天赋时，不光给他增加一个新的dot、并且在这个新dot的存在期间，还要保护他的两个dot性疾病和1个debuf性疾病不被驱散！


继续补充：在WLK里面，那个脑袋都被子弹打成筛子了的暴雪设计师又跳出来了，用他满是漏洞的脑子出了个该杀的主意：他要求添加载具概念，当玩家坐上载具时，临时删除他的所有技能，替换为载具的技能；或者当他坐在特定载具的特定位置时，防止他受到任何伤害、并且允许他释放自己的所有技能！
更该死的是，他要求，一些技能本来不允许在移动中施放；但现在，当玩家坐在载具上某个位置时，要临时允许他移动施法！

还有，为了平衡某个野外战场，他还要求，在某方人数较少时，临时根据提高他们的生命值和所有技能的攻击力和治疗能力——这个改变必须根据进入战场的人数实时进行；在一方连续在某个战场失败时，同样要给他们一定补偿！



嗯嗯，看看这些不断改变的刁钻需求吧，如果没有面向对象，没有以策略模式为首的28个设计模式(我有理由相信你们需要至少28个设计模式而不是23个)的英明领导，我们这些没接触过大项目、不懂面向对象的傻B们，就是哭的拿眼泪把长城溶解掉都没办法吧？——我当然知道搭建长城的材料极难溶与水。

可怜的瞎子，你们的鱼汤很鲜吧？

嗯，到这里，希望读者们也能停下来，好好思考一下，看看这个问题该如何解决。














想到了没有？
这里是答案，看看你的想法是否能不谋而合吧：

这个问题暴雪在Diablo 2时代已经完美解决了： 法术/技能数据库化


所谓数据库化，其实等同于表格化，例如这个随便杜撰出来的简化方案，是设计一个有如下字段的数据表格：

法术ID 动画效果 作用范围 作用类型 属性 特殊限制 强化类型 特殊设定


其中，特殊设定字段可以是一段LUA代码，可以在其中搜索、设置极其特殊的伤害类型，或者查询顺劈斩/治疗链等奇特技能的传递目标等等。

特殊限制字段设定法术的施法或/和生效条件，如驱散限定为只能作用于魔法性buf/debuf（根据职业不同，可能有进攻性驱散和防守性驱散之一，也可能同时具备——这就体现在可否驱散敌方/友方目标的debuf）



在这个方案下，释放一个法术/技能，就成为一种查表运算——找到此法术ID，找到它的作用类型和伤害属性，计算特殊设定（包括但不限于顺劈斩模式的判断、天赋加成和天赋效果、雕文加成和雕文效果等等）。

于是，到最后，整个法术体系被分为一组组的魔法buf/debuf、物理buf/debuf，这些buf/debuf会影响伤害公式中的某个因子或者造成伤害效果；而伤害效果又分为立即伤害/立即治疗和持续伤害/持续治疗；最后则是一套影响范围判定机制。


举例来说，骑士开圣盾，他同时得到一个buf和一个debuf。
buf是“无敌”，效果相当于设置伤害公式 a*(....) 前面的a因子为0（没有无敌时此因子为1），于是所有伤害无效。
debuf则是“自律”，因为他的圣盾、圣疗技能判断条件里都有“有自律debuf，则不允许使用”的设定，于是禁止他在短时间内再次使用这些无赖技能。

敌方法师对他释放寒冰箭，系统受理，但查询骑士状态，发现他处于无敌状态，返回大大的两个字“免疫”。

然后，有一个敌方牧师对他使用驱散，查询牧师的驱散术发现，在驱散术的可驱散列表里没有圣盾术，于是提示无法驱散或驱散了另外的可驱散（魔法）效果。
敌方牧师迅速反应过来，再次对他使用强力驱散；查询牧师强力驱散术，发现该牧师在不久前使用过强力驱散，提示无法施法。
等待3秒后，敌方牧师发现自己的强力驱散冷却（cool down），再次使用强力驱散，查询发现强力驱散可驱散圣盾术，于是成功移除骑士的无敌状态。

现在，敌方法师再次对他释放寒冰箭，骑士切换冰抗光环，系统查询骑士状态，发现冰抗光环，又查询法师穿透等级，和暴击等级，根据公式计算能否命中、能否造成全额伤害以及能否暴击；然后提取法师和骑士双方装备、天赋数据代入公式计算伤害加成、减免数据，最后给出骑士受到的伤害数字（包括部分抵抗了多少）。



在暴雪设计师的整理之下，如上种种最终构成了几个表格；只要查询并代入相应的数据，即可计算出伤害/治疗数值以及类型；特殊效果可以用存储在数据库中的LUA代码补充完成。

最终的设计效果就好像内嵌了一个解释器，这个解释器会根据法术ID解释执行数据库内部的相关内容。


这样一来，只要伤害公式、伤害/buf类型、动画效果等等就位，那么新增一个法术就只不过是在数据库中新增一条记录；让某个角色学会一个新法术，则只需在它的可使用法术列表里添加法术名称（或法术ID）；释放法术是根据法术ID在数据库中提取动画；计算伤害是根据法术ID读取伤害公式，然后代入相关字段并求值。

而这一切，甚至可以通过内部实现的编辑器，用图形界面完成。


如何？无与伦比的扩展性和便利性，是吧？

这么一整套东西，核心代码很可能只有数千甚至数百行。这是因为看似复杂的光环、buf等等东西，其实都已经抽象到和其他法术同样的流程上来了。最终，所有这些全部归一为解释执行伤害公式、提取执行指定动画之类寥寥几个通用过程——这显然同样是封装和归一化思想结出的另一颗果实。但为什么你就是想不到封装和归一化还能这样用？很简单，因为你被那些只会就着浅显的多态喋喋不休的笨蛋彻底引偏方向了。

我并没有亲自实现过这个，所以不敢断定这玩意儿靠几百行代码真的就能全部实现；但根据我在其它项目上的经验，这套东西应该就是数百行代码就可以写出来的——但写出并调试好这数百行代码所需的时间可能是一个星期甚至一个月。

相比于不假思索的写下class所必然导致的庞大、复杂的类层次，以及扯来扯去蛋疼无比的复杂的设计模式大网，这玩意儿的实现、维护、修改、扩展的便利程度，显然不是一个量级的：前者可能数百人努力数年、弄出几百万行代码都不能正确实现需求，而且必然bug满天飞；而后者，一个人，个把月，千把行代码，完成。如果实现水平足够的话，写完就再不用碰代码，而是去写图形编辑工具了。之后，扩展、维护都不过是用自己实现的工具拖来拖去再改改属性、数值，然后点存盘写入数据库，完事。


所以说，万不可死板的傻抱着面向对象不放。你所面对的问题才是最重要的。
你必须随机应变给出合适的方案——至于最后的设计方案会是什么流派，那玩意儿根本无关紧要。拿出一个简单、有效、可靠的方案，比什么都重要。

最后，还是我在前文总结的那句话：

封装可（通过固定接口而）应付需求变更、归一化可简化（类的使用者的）设计：以上，就是面向对象最最基本的好处。其它一切，都不过是在这两个基础上的衍生而已。

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

再强调一遍，应付需求变更/简化设计并不是空洞的宣传口号。

封装和归一化类似军队制度建设，目标是搞出一个标准化、立体、多变、高效的指挥体系，从而获得打大战、打硬战的能力，然后再去轻松碾压问题。此所谓战略。

而那些堆砌无用的所谓“设计模式”的家伙，其实是在每个零件表面粘上挂钩——据他们说，这样会增加灵活性、应对需求变更、简化设计：比如说你带了个包，就可以挂他们在飞轮上粘的那个勾子上。

但实际上，你永远不会把包挂飞轮上（但你还是不得不为那些”聪明绝顶“的家伙“为了避免飞轮上的钩子脱落、挂住其它零件、离心力太大破坏挂在上面的包”等等而衍生出的”杰出“设计买单）。
幸运的是，除了某些企业项目（或其他类似性质的项目），你并不会用到这么烂的东西。因为这些笨蛋到处乱粘的钩子会不可避免的导致整个项目变成黏糊糊的一团，从而在旷日持久的拖延后自杀。

这种做法，显然是和面向对象的初心——通过封装和归一化获得高效指挥体系——背道而驰，从而使得每个中了这种毒的家伙参与的项目不可避免的成为一滩稀屎。

所以，很遗憾，只有杀马特设计师才会这样做。真正的设计师压根不会在设计发动机时考虑“飞轮上挂包”这样的需求（这就叫“以不知所谓的战术投机代替战略布局”）。他会干净利落的在整车设计时加个后备箱。




请注意，这并不是个比喻。

如你所见，在”每个零件上粘上挂钩“这种事情实在太过疯狂，所以在其他行业连玩笑都不是，因为再傻的人都不会这么做。

然而在软件设计时……这种事情是如此多见，多见到面向对象的领军人物会推荐别人这样做（如此理解面向对象编程）；多见到业内很多大佬都不得不站出来，怒斥”面向对象是个骗局“。

名家吐槽：面向对象编程从骨子里就有问题
“面向对象编程是一个极其糟糕的主意，只有硅谷里的人能干出这种事情。” — Edsger Dijkstra(图灵奖获得者)

Edsger W. Dijkstra

如此沉重的心智负担，这显然是面向对象的原罪。