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

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

1、面向对象原本要解决什么（或者说有什么优良特性）

似乎很简单，但实际又很不简单：面向对象三要素封装、继承、多态

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

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

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

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

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

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

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

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

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

继承的第二种含义非常重要。它又叫“接口继承”。

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

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

归一化的实例：

a、一切对象都可以序列化/toString

b、一切UI对象都是个window，都可以响应窗口事件。

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

显然，归一化可以大大简化使用者的处理逻辑：

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

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

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

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