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

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

所以说，万不可死板的傻抱着面向对象不放。你所面对的问题才是最重要的。

你必须随机应变给出合适的方案——至于最后的设计方案会是什么流派，那玩意儿根本无关紧要。拿出一个简单、有效、可靠的方案，比什么都重要。

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

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

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

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

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

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

但实际上，你永远不会把包挂飞轮上（但你还是不得不为那些”聪明绝顶“的家伙“为了避免飞轮上的钩子脱落、挂住其它零件、离心力太大破坏挂在上面的包”等等而衍生出的”杰出“设计买单）。

幸运的是，除了某些企业项目（或其他类似性质的项目），你并不会用到这么烂的东西。因为这些笨蛋到处乱粘的钩子会不可避免的导致整个项目变成黏糊糊的一团，从而在旷日持久的拖延后自杀。

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

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

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

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

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

名家吐槽：面向对象编程从骨子里就有问题

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

Edsger W. Dijkstra

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

作者：invalid s

链接：https://www.zhihu.com/question/20275578/answer/26577791

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