实际上也就是要满足LSP原则,水果类<-榴莲的继承是特化
二,派生类必须知道他们的基类,基类不应当知道他们的派生类
复用的前提
复用的前提
三,基类中的所有数据都应该是私有的,不要使用保护数据(方法不在此原则约束下)
数据封装，物体的重量看起来可以用一个保护数据来表达，而不是get/set方法，但是考虑其他星球上，那么重量的应该实现为质量*加速度的时候呢？
数据封装，物体的重量看起来可以用一个保护数据来表达，而不是get/set方法，但是考虑其他星球上，那么重量的应该实现为质量*加速度的时候呢？
四，理论上，继承层次越深越好
继承越深，意味着复用的功能越多
继承越深，意味着复用的功能越多
五，如果没有合适的可视化工具显示类继承层次，那么在实践中，继承层次最合适的深度是7+-2（7是一个神奇的数字，是一个普通人能保持短期记忆的数字）
六,所有的抽象类都应该是基类
没有派生类的抽象类毫无意义,连创建都创建不了
没有派生类的抽象类毫无意义,连创建都创建不了
七,与六对应,所有的基类都应该是抽象类
违反这条原则的后果是将来可能会有大量的改名操作(在进一步抽象的过程中类名不在合适,在适应变化的时候会出现)
违反这条原则的后果是将来可能会有大量的改名操作(在进一步抽象的过程中类名不在合适,在适应变化的时候会出现)
八,把数据,行为和/或接口的共性尽可能地放到继承层次的高端
公共数据经常意味着公共行为
公共数据经常意味着公共行为
九,如果两个或多个类共享公共数据(但没有公共行为),那应该把公共数据放在一个类中,给个共享这些数据的类都包含这个类(而不是继承)
继承所抽象的是行为,而不是数据,和八对应.
对静态不变的类型/数据进行判断的代码基本上可以说是设计不到位的表现,如针对水果而言
if(type is apple)...
else if(type is orrange) ...
...
但是对可变的数据进行判断在一定程度上可以接受,但是如果逻辑复杂,则需要考虑状态机/策略来封装.
继承所抽象的是行为,而不是数据,和八对应.
对静态不变的类型/数据进行判断的代码基本上可以说是设计不到位的表现,如针对水果而言
if(type is apple)...
else if(type is orrange) ...
...
但是对可变的数据进行判断在一定程度上可以接受,但是如果逻辑复杂,则需要考虑状态机/策略来封装.
十一,如果两个类或更多类共享公共接口,那么只有他们需要被多态使用时,才需要公共基础类.
如果不需要多态使用,干什么要继承而不是组合,组合优于继承
如果不需要多态使用,干什么要继承而不是组合,组合优于继承
十三,对属性值的显式分情况分析常常是错误的.类应该解耦合成一个继承层次结构,每个属性值都被变换成一个派生类
红绿黄球的例子
如果颜色不影响到球的行为,则不需要抽象一个球的基础类,然后派生3个颜色球类
反之,则需要
红绿黄球的例子
如果颜色不影响到球的行为,则不需要抽象一个球的基础类,然后派生3个颜色球类
反之,则需要
十四,不要通过继承关系来为类的动态语义建立模.试图用静态语义关系来为动态语义建模会导致在运行时切换类型
如门的状态属性:开和关,千万不要出现OpenedDoor和ClosedDoor类,试图用状态机来处理.
如门的状态属性:开和关,千万不要出现OpenedDoor和ClosedDoor类,试图用状态机来处理.
十五,不要把类的对象变成派生类.对任何只有一个实例的派生类都要警惕.
如下面的继承关系就是问题：
汽车制造商<=
福特
大众
本田
如下面的继承关系就是问题：
汽车制造商<=
福特
大众
本田
十六,如果你觉得需要在运行时创建新的类,那么请退一步仔细想想是不是要创建对象.把这些对象概括成一个类
组合模式是一个很明显的例子
组合模式是一个很明显的例子
十八,不要把可选包含(可能为null的属性)同对继承的需要混淆起来.否则会带来泛滥成灾的类.
狗<=会摇尾巴的狗,不会摇尾巴的狗,尾巴受伤的狗,等等
狗<=会摇尾巴的狗,不会摇尾巴的狗,尾巴受伤的狗,等等
十九,在创建继承层次时,试着创建可复用的框架,而不是可复用的类
关注创建的是接口,而不是具体的类.与DIP原则类似
关注创建的是接口,而不是具体的类.与DIP原则类似
经典故事:
按照第一想法,所有的哺乳动物都是怀胎产子,矛盾在鸭嘴兽是哺乳动物,但是是蛋生,那么我们该怎么建立模型呢?
