浏览次数：800次 知乎 2014年07月14日
当前很多资料都在讲述面向对象的优点，可是在软件开发或者大型软件项目中，面向对象却带来了巨大的类关系设计开销，但具体有何弊端却没有详尽的介绍。
nvalid s
弊端是，没有人还记得面向对象原本要解决的问题是什么。
1、面向对象原本要解决什么（或者说有什么优良特性）
似乎很简单，但实际又很不简单：面向对象三要素封装、继承、多态
（警告：事实上，从业界如此总结出这面向对象三要素的一刹那开始，就已经开始犯错了！）。
封装：封装的意义，在于明确标识出允许外部使用的所有成员函数和数据项，或者叫接口。
有了封装，就可以明确区分内外，使得类实现者可以修改封装内的东西而不影响外部调用者；而外部调用者也可以知道自己不可以碰哪里。这就提供一个良好的合作基础——或者说，只要接口这个基础约定不变，则代码改变不足为虑。
继承+多态：继承和多态必须一起说。一旦割裂，就说明理解上已经误入歧途了。
先说继承：继承同时具有两种含义：其一是继承基类的方法，并做出自己的扩展——号称解决了代码重用问题；其二是声明某个子类兼容于某基类（或者说，接口上完全兼容于基类），外部调用者可无需关注其差别（内部机制会自动把请求派发[dispatch]到合适的逻辑）。
再说多态：基于对象所属类的不同，外部对同一个方法的调用，实际执行的逻辑不同。
很显然，多态实际上是依附于继承的第二种含义的。让它与封装、继承这两个概念并列，是不符合逻辑的。不假思索的就把它们当作可并列概念使用的人，显然是从一开始就被误导了。
实践中，继承的第一种含义（实现继承）意义并不很大，甚至常常是有害的。因为它使得子类与基类出现强耦合。
继承的第二种含义非常重要。它又叫“接口继承”。
接口继承实质上是要求“做出一个良好的抽象，这个抽象规定了一个兼容接口，使得外部调用者无需关心具体细节，可一视同仁的处理实现了特定接口的所有对象”——这在程序设计上，叫做归一化。
归一化使得外部使用者可以不加区分的处理所有接口兼容的对象集合——就好象linux的泛文件概念一样，所有东西都可以当文件处理，不必关心它是内存、磁盘、网络还是屏幕（当然，如果你需要，当然也可以区分出“字符设备”和“块设备”，然后做出针对性的设计：细致到什么程度，视需求而定）。
归一化的实例：
a、一切对象都可以序列化/toString
b、一切UI对象都是个window，都可以响应窗口事件。
——必须注意，是一切（符合xx条件的）对象皆可以做什么，而不是“一切皆对象”。后者毫无意义。
显然，归一化可以大大简化使用者的处理逻辑：这和带兵打仗是类似的，班长需要知道每个战士的姓名/性格/特长，否则就不知道该派谁去对付对面山坡上的狙击手；而连长呢，只需知道自己手下哪个班/排擅长什么就行了，然后安排他们各自去守一段战线；到了师长/军长那里，他更关注战场形势的转变及预期……没有这种层层简化、而是必须直接指挥到每个人的话，累死军长都没法指挥哪怕只是一场形势明朗的冲突——光一个个打完电话就能把他累成哑巴。
软件设计同样。比如说，消息循环在派发消息时，只需知道所有UI对象都是个window，都可以响应窗口消息就足够了；它没必要知道每个UI对象究竟是什么——该对象自己知道收到消息该怎么做。
合理划分功能层级、适时砍掉不必要的繁杂信息，一层层向上提供简洁却又完备的信息/接口，高层模块才不会被累死——KISS是最难也是最优的软件设计方法，没有之一。
总结：面向对象的好处实际就这么两点。
一是通过封装明确定义了何谓接口、何谓接口内部实现、何谓接口的外部调用者，使得大家各司其职，不得越界；
二是通过继承+多态这种内置机制，在语言的层面支持归一化的设计，并使得内行可以从代码本身看到这个设计——但，注意仅仅只是支持归一化的设计。不懂如何做出这种设计的外行仍然不可能从瞎胡闹的设计中得到任何好处。
显然，不用面向对象语言、不用class，一样可以做归一化的设计（如老掉牙的泛文件概念、游戏行业的一切皆精灵），一样可以封装（通过定义模块和接口），只是用面向对象语言可以直接用语言元素显式声明这些而已；
而用了面向对象语言，满篇都是class，并不等于就有了归一化的设计。甚至，因为被这些花哨的东西迷惑，反而更加不知道什么才是设计。
2、人们以为面向对象是什么、以及因此制造出的悲剧以及闹剧
误解一、面向对象语言支持用语言元素直接声明封装性和接口兼容性，所以用面向对象语言写出来的东西一定更清晰、易懂。
事实上，既然class意味着声明了封装、继承意味着声明了接口兼容，那么错误的类设计显然就是错误的声明、盲目定义的类就是无意义的喋喋不休。而错误的声明比没有声明更糟；通篇毫无意义的喋喋不休还不如错误的声明。
除非你真正做出了漂亮的设计，然后用面向对象的语法把这个设计声明出来——仅仅声明真正有设计、真正需要人们注意的地方，而不是到处瞎叫唤——否则不可能得到任何好处。
一切皆对象实质上是在鼓励堆砌毫无意义的喋喋不休。大部分人——注意，不是个别人——甚至被这种无意义的喋喋不休搞出了神经质，以至于非要在喋喋不休中找出意义：没错，我说的就是设计模式驱动编程，以及如此理解面向对象编程
误解二、面向对象三要素是封装、继承、多态，所以只要是面向对象语言写的程序，就一定“继承”了语言的这三个优良特性。
事实上，如前所述，封装、继承、多态只是语言层面对良好设计的支持，并不能导向良好的设计。
如果你的设计做不出真正的封装性、不懂得何谓归一化，那它用什么写出来都是垃圾。
误解三、把软件写成面向对象的至少是无害的。
要了解事实上是什么，需要先科普几个概念。
什么是真正的封装？
——回答我，封装是不是等于“把不想让别人看到、以后可能修改的东西用private隐藏起来”？
显然不是。
如果功能得不到满足、或者未曾预料到真正发生的需求变更，那么你怎么把一个成员变量/函数放到private里面的，将来就必须怎么把它挪出来。
你越瞎搞，越去搞某些华而不实的“灵活性”——比如某种设计模式——真正的需求来临时，你要动的地方就越多。
真正的封装是，经过深入的思考，做出良好的抽象，给出“完整且最小”的接口，并使得内部细节可以对外透明（注意：对外透明的意思是，外部调用者可以顺利的得到自己想要的任何功能，完全意识不到内部细节的存在；而不是外部调用者为了完成某个功能、却被碍手碍脚的private声明弄得火冒三丈；最终只能通过怪异、复杂甚至奇葩的机制，才能更改他必须关注的细节——而且这种访问往往被实现的如此复杂，以至于稍不注意就会酿成大祸）。
一个设计，只有达到了这个高度，才能真正做到所谓的“封装性”，才能真正杜绝对内部细节的访问。
否则，生硬放进private里面的东西，最后还得生硬的被拖出来——当然，这种东西经常会被美化成“访问函数”之类渣渣（不是说访问函数是渣渣，而是说因为设计不良、不得不以访问函数之类玩意儿在封装上到处挖洞洞这种行为是渣渣）。
一个典型的例子，就是C++的new和过于灵活的内存使用方式之间的耦合。
这个耦合就导致了new[]/delete[]、placement new/placement delete之类怪异的东西：这些东西必须成对使用，怎么分配就必须怎么释放，任何错误搭配都可能导致程序崩溃——这是为了兼容C、以及得到更高执行效率的无奈之举；但，它更是“抽象层次过于复杂，以至于无法做出真正透明的设计”的典型案例：只能说，c++设计者是真正的大师，如此复杂的东西在他手里，才仅仅付出了如此之小的代价。
(更准确点说，是new/delete和c++的其它语言元素之间是非正交的；于是当同时使用这些语言元素时，就不可避免的出现了彼此扯淡的现象。即new/delete这个操作对其它语言元素非透明：在c++的设计里，是通过把new/delete分成两层，一是内存分配、二是在分配的内存上初始化，然后暴露这个分层细节，从而在最大程度上实现了封装——但比之其它真正能彼此透明的语言元素间的关系，new/delete显然过于复杂了)
这个案例，可以非常直观的说明“设计出真正对外透明的封装”究竟会有多难。
接口继承真正的好处是什么？是用了继承就显得比较高大上吗？
显然不是。
接口继承没有任何好处。它只是声明某些对象在某些场景下，可以用归一化的方式处理而已。
换句话说，如果不存在“需要不加区分的处理类似的一系列对象”的场合，那么继承不过是在装X罢了。
封装可应付需求变更、归一化可简化（类的使用者的）设计：以上，就是面向对象最最基本的好处。
——其它一切，都不过是在这两个基础上的衍生而已。
换言之，如果得不到这两个基本好处，那么也就没有任何衍生好处——应付需求变更/简化设计并不是打打嘴炮就能做到的。
了解了如上两点，那么，很显然：
1、如果你没有做出好的抽象、甚至完全不知道需要做好的抽象就忙着去“封装”，那么你只是在“封”和“装”而已。
这种“封”和“装”的行为只会制造累赘和虚假的承诺；这些累赘以及必然会变卦的承诺，必然会为未来的维护带来更多的麻烦，甚至拖垮整个项目。
正是这种累赘和虚假的承诺的拖累，而不是所谓的为了应付“需求改变”所必需的“灵活性”，才是大多数面向对象项目代码量暴增的元凶。
2、没有真正的抓到一类事物（在当前应用场景下）的根本，就去设计继承结构，是必不会有所得的。
不仅如此，请注意我强调了在当前应用场景下。
这是因为，分类是一个极其主观的东西，不存在普适的分类法。
举例来说，我要研究种族歧视，那么必然以肤色分类；换到法医学，那就按死因分类；生物学呢，则搞门科目属种……
想象下，需求是“时尚女装”，你却按“窒息死亡/溺水死亡/中毒死亡之体征”来了个分类……你说后面这软件还能写吗？
类似的，我遇到过写游戏的却去纠结“武器装备该不该从游戏角色继承”的神人。你觉得呢？
事实上，游戏界真正的抽象方法之一是：一切都是个有位置能感受时间流逝的精灵；而某个“感受到时间流逝显示不同图片的对象”，其实就是游戏主角；而“当收到碰撞事件时，改变主角下一轮显示的图片组的”，就是游戏逻辑。
看看它和“武器装备该不该从游戏角色继承”能差多远。想想到得后来，以游戏角色为基类的方案会变成什么样子？为什么会这样？
最具重量级的炸弹则是：正方形是不是一个矩形？它该不该从矩形继承？如果可以从矩形继承，那么什么是正方形的长和宽？在这个设计里，如果我修改了正方形的长，那么这个正方形类还能不能叫正方形？它不应该自然转换成长方形吗？什么语言能提供这种机制？
造成这颗炸弹的根本原因是，面向对象中的“类”，和我们日常语言乃至数学语言中的“类”根本就不是一码事。
面向对象中的“类”，意思是“接口上兼容的一系列对象”，关注的只不过是接口的兼容性而已（可搜索 里氏代换）；关键放在“可一视同仁的处理”上（学术上叫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，那它就是个好设计。
的确有成功的经验、正确/合理的方向：技术无罪，但，没有银弹。
pansz，欢迎评论
可能我的看法有些简单粗暴。但是我希望表达一下我的「一家之言」。
面向对象编程有很多用途，很多用法，但是我们会发现「设计模式驱动」成为了非常有代表性的流派。有时我们会疑惑，为什么会有设计模式，为什么面向对象编程会出现如此恐怖的这么复杂的类关系。
我认为这是为了满足「增量式开发」。它假定几个前提：
1，将一份代码测试调试稳定所需要花的时间，远远大于撰写代码的时间。
2，已经通过测试的旧代码永远不修改，只对新代码进行新增，是最可靠的开发方式。
3，你经常需要重用没有源代码的库，并且扩展和修改其功能。
很多面向对象的设计，其实是为了满足一个很基本的目的：不修改旧代码，只新增代码。代码只增不改，所以才会出现「继承」这种东西。因为你不需要原有的源代码也不需要修改原有的类，而是派生一个类增加新的方法。「继承」的本来目的看起来就是为了解决这个问题。
因此，很多类层次关系的设计，不是为了更高的效率，不是为了代码看起来更清晰，而是为了「保证旧代码不需要被修改」这个目的。
不过，这是不是现实呢？在某些公司，这是事实，在很多公司，以上的假定不是现实。
1，很多代码并没有经过长时间的充分的测试，因而没有必要为了不浪费原有测试资源而拒绝修改旧代码。
2，修改旧代码在大多数公司是不可避免的。
3，很多时候我们提倡读懂库的源代码，而不会盲目使用无源代码的库。
4，现在流行的敏捷开发模型中宣传要拥抱变化。在敏捷模型中，测试案例是被固化的，而代码与架构都可以经常被修改，换句话说，不修改旧代码，以及通过类层次关系设计系统架构，这些特性对敏捷来说都不重要，甚至背道而驰。
我的看法与 酷壳「如此理解面向对象编程」恰恰相反，他认为过度 OO 设计是敏捷带来的后果，而我认为敏捷开发恰恰使得过度 OO 设计变得毫无意义。——那些过度 OO 设计的人并没有真正的懂敏捷。真正的敏捷是在保证测试案例通过的前提下，直接简单粗暴的修改源代码，而不是为了避免修改三行源代码制造出十多个类。
如果我们的开发基于「旧代码就是需要被经常修改的」，那么面向对象中的一部分特性其实变成了毫无意义的累赘。当然这并意味着 OOP 完全无用，在这个前提下，其实我们需要重新审视面向对象的程序设计，取其精华去其糟粕。
封装性，继承性，多态性，这些特性在敏捷开发的情况下还那么重要吗？
封装性：在所有代码都公开，随时可能被修改被重构的情况下，封装性意义没有想象的那么大，虽然它仍然有价值。它的价值在于使程序行为更可预期。
继承性：继承的本目的是在不修改代码的情况下扩展代码的功能，但如果我们能够自由修改代码，那继承在绝大多数时候并不是最佳选择。事实上，巨大的类设计开销往往都是继承性带来的。继承性在今天不但没有太大的价值，反而常常有害。（这里所说的继承性指的是 invalid s 所说的第一种情况，对他说的第二种情况，我不认为那算作继承性，而应该被算作多态性。）
多态性：多态性要求一个函数在接受不同的类型对象作为参数时自动表现出不同的行为。或者说要求不同类型的对象都可以调用相同名字的方法，并且自己处理应该有的不同行为。——这个特性在今天依然重要，而且是最重要的特性，它的存在意味着 OOP 的价值仍然存在——即便对于非 OOP 的程序设计语言。只要应用了多态性思想，那么其实它就是 OOP 的。考虑一下 Linux 中的「一切皆文件」的概念，其实换句话说就是对一切对象皆可调用用于文件的那些方法，这妥妥的是「多态性」。图形界面的编程 API 中，一切对象皆可 Paint()，一切对象皆可 toString()，这妥妥的也是「多态性」。
从某种意义上说，「模板」这个一般认为不属于 OOP 的特性，却非常好的体现了多态性。模板允许同名函数接收不同类型的参数自动表现出不同的行为（虽然编译器实际上是生成了多个函数，但从编程的角度来讲它其实是一个函数）。因此我认为懂得模板技术在 OOP 设计中也非常重要，他用更小的开销更好的可读性实现了 OOP 思想。
结语：很多时候，巨大的类关系设计开销是为了避免修改旧代码而不是为了使代码更可读。而在修改旧代码不可避免或者根本不需要避免的时候，很多类关系设计开销是不必要的，我们在使用面向对象设计方法时，最好是取其精华去其糟粕，避免那些额外的不必要的类设计开销，以提升代码的可读性为目标来进行设计，而不要以避免修改代码为目标进行设计，在这种情况下 OOP 仍然有其存在的价值。
Milo Yip，游戏程序员、《游戏引擎架构》译者
想从一个游戏程序员的角度探讨OOP的一个问题──性能。
现时C++可以说是支持OOP范式中最为常用及高性能的语言。虽然如此，在C++使用OOP的编程方式在一些场合未能提供最高性能。 [1]详细描述了这个观点，我在此尝试简单说明。注意：其他支持OOP的语言通常都会有本答案中提及的问题，C++只是一个合适的说明例子。
历史上，OOP大概是60年代出现，而C++诞生于70年代末。现在的硬件和当时的有很大差异，其中最大的问题是内存墙_百度百科。
图1: 处理器和内存的性能提升比较，处理器的提升速度大幅高于内存[2]。
跟据Numbers Every Programmer Should Know By Year：
图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
冯东，Adobe 程序员
面向对象的弊端在于作为一种建模技术没有很好的定义自己的适用范围。面向对象脱胎的环境有两个重要因素，一是基于 WIMP (Window, Icon, Menu, Pointer) 的图形化界面，二是早期提供图形界面接口的机器缺乏代码级别之外的组件管理方式 (比如 Unix 的进程和 IPC)。
面向对象在 WIMP 的环境中是很必要也是很成功的。原因是 WIMP 环境需要重量的实现继承提供的重用，WIMP 的对象种类能很好的被单继承模拟，WIMP 的属性和类别容易区分。而面向对象扩展到 WIMP 之外的环境中就失败了：
- 实际世界是多纬度的，属性和类别不好区分。红苹果是 color 属性为 red 的苹果，还是 Apple 的子类？
- 实际世界的工具是用来完成任务的。而不是象 WIMP 那样构建一个虚拟的空间化界面。
- 《人月神话》指出，编写 reusable code 比编写普通 code 至少要多花三倍的工作量。而面向对象的模糊了代码的重用和使用。使被重用的代码的依赖复杂化。导致很多不适合被重用的代码被重用。编写代码时要过分考虑重用的可能性。
- 其它管理复杂度的机制越来越流行。