《为耦合辩护,为继承伸冤》的补充

《为耦合辩护,为继承伸冤》一文草草而成,又不太完整,
结尾处还打了个白条,可能易引起误解,先简介一下,在把大部
分回复一齐回复一下.这个白条可能在下次兑付.

《为耦合辩护,为继承伸冤》谈了两个问题:

一.耦合并不是绝对坏的东西,分5点讲
1.不耦合和低耦合在很多情况下不太可能被实现;
2.低耦合并不是最重要的事情重要;
3.低耦合有时没有多大好处;
4.高耦合也常常有好处;
5.高耦合带来的害处是可以化解的.

二.用继承并不一定比聚合耦合度高,分3点讲
1.高耦合的部分往往用继承实现,低耦合的部分往往用聚合
实现,所以带来的用继承比用聚合耦合度高的错觉;
2.聚合和相识关系有时也需要高耦合;
3.可以设法降低继承的耦合度.

我同意以下说法:“建模时用继承还是聚合，均可，哪种结
构表达最接近自然，就用哪种－－先放下程序设计上的考虑。”
同时认为设计时用继承还是聚合也应尽量使用表达最接近自然的
那一种.

有人说:“继承少用最好,那仅仅是一种产生对象类别的方法,
使用对象的精髓还在于聚合. ”我只能说,聚合也那仅仅是一种产
生对象类别的方法,而且很抱歉,我至今不认为存在什么“使用对象
的精髓”.

至于“继承属于OOP范畴”好象是属于搞笑范畴.

“过多的继承会增加基类的修改难度，从而降低了设计的灵
活性”我认为有道理,但设计的灵活性主要应建立在一个不需要
大修改的基类的基础上,基类需要大改动很可能是从分析开始出
了问题.

接口与聚合和继承都没有直接关系,接口实际上是标准化的
封装,我所设想的继承接口是标准化的继承.

“pb也是由继承机制的，难道他就是面向对象的？” PB为什
么不能算面向对象的呢?“oo强调每个对象应该专注于某个功能。
应尽可能的把对象写的功能单一小巧。”结构化也强调每个模块
应该专注于某个功能,也应尽可能的把模块写的功能单一小巧。
“大部分时候，基本上都可以用delegate来代替了。”我的观点,
用delegate来代替继承不够自然,而且有缺陷,我将在其他文章中
专文讨论.

对于继承往往是静态的,我认为主要应通过改进继承机制来解
决,我也将在其他文章中专文讨论.

很多人言必称《设计模式》,就象基督徒对《圣经》,穆斯林
对《古兰经》一样.我个人以为《设计模式》不适合做面向对象设
计方面的启蒙读物,也不太适合做面向对象设计方面的《圣经》.
其他有关《设计模式》的问题,我还是将在其他文章中专文讨论.

很抱歉,第一个白条没兑付,又打了好几个白条.