OOD沉思录之继承

一,继承只应被用来为特化层次结构建模
实际上也就是要满足LSP原则,水果类<-榴莲的继承是特化

二,派生类必须知道他们的基类,基类不应当知道他们的派生类
复用的前提

三,基类中的所有数据都应该是私有的,不要使用保护数据(方法不在此原则约束下)
数据封装，物体的重量看起来可以用一个保护数据来表达，而不是get/set方法，但是考虑其他星球上，那么重量的应该实现为质量*加速度的时候呢？

四，理论上，继承层次越深越好
继承越深，意味着复用的功能越多

五，如果没有合适的可视化工具显示类继承层次，那么在实践中，继承层次最合适的深度是7+-2（7是一个神奇的数字，是一个普通人能保持短期记忆的数字）

六,所有的抽象类都应该是基类
没有派生类的抽象类毫无意义,连创建都创建不了

七,与六对应,所有的基类都应该是抽象类
违反这条原则的后果是将来可能会有大量的改名操作(在进一步抽象的过程中类名不在合适,在适应变化的时候会出现)

八,把数据,行为和/或接口的共性尽可能地放到继承层次的高端
公共数据经常意味着公共行为

九,如果两个或多个类共享公共数据(但没有公共行为),那应该把公共数据放在一个类中,给个共享这些数据的类都包含这个类(而不是继承)
继承所抽象的是行为,而不是数据,和八对应.
对静态不变的类型/数据进行判断的代码基本上可以说是设计不到位的表现,如针对水果而言
if(type is apple)...
else if(type is orrange) ...
...
但是对可变的数据进行判断在一定程度上可以接受,但是如果逻辑复杂,则需要考虑状态机/策略来封装.

十,如果两个或多个类有共同的数据和行为(就是方法),那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承

十一,如果两个类或更多类共享公共接口,那么只有他们需要被多态使用时,才需要公共基础类.
如果不需要多态使用,干什么要继承而不是组合,组合优于继承

十二,对对象类型的显式的分情况分析一般都是错误的设计.在大多数这种情况下,设计者应当使用多态
如：
如果你是类型A,则做这件事
如果你是类型B,则做那件事
如果你是类型C,则做其他的一件事

十三,对属性值的显式分情况分析常常是错误的.类应该解耦合成一个继承层次结构,每个属性值都被变换成一个派生类
红绿黄球的例子
如果颜色不影响到球的行为,则不需要抽象一个球的基础类,然后派生3个颜色球类
反之,则需要

十四,不要通过继承关系来为类的动态语义建立模.试图用静态语义关系来为动态语义建模会导致在运行时切换类型
如门的状态属性:开和关,千万不要出现OpenedDoor和ClosedDoor类,试图用状态机来处理.

十五,不要把类的对象变成派生类.对任何只有一个实例的派生类都要警惕.
如下面的继承关系就是问题：
汽车制造商<=
福特
大众
本田

十六,如果你觉得需要在运行时创建新的类,那么请退一步仔细想想是不是要创建对象.把这些对象概括成一个类
组合模式是一个很明显的例子

十七,在派生类中用空方法来覆盖基类中的方法应该是非法的.
如果这样做可行的话,任何类都可以成为任何其他类的派生类,反正把基类的所有方法都用空方法屏蔽掉然后加自己的方法就是.

十八,不要把可选包含(可能为null的属性)同对继承的需要混淆起来.否则会带来泛滥成灾的类.
狗<=会摇尾巴的狗,不会摇尾巴的狗,尾巴受伤的狗,等等

十九,在创建继承层次时,试着创建可复用的框架,而不是可复用的类
关注创建的是接口,而不是具体的类.与DIP原则类似

经典故事:

按照第一想法,所有的哺乳动物都是怀胎产子,矛盾在鸭嘴兽是哺乳动物,但是是蛋生,那么我们该怎么建立模型呢?

原文链接：https://www.f2er.com/javaschema/286889.html

OOD沉思录 之 继承

猜你在找的设计模式相关文章