OOD沉思录1

OOD沉思录 之 导引
  一个对象一定会有如下4个属性:
     1,它的身份标示,可能只是它在内存中的地址;
     2,它的类的属性(通常是静态属性)和这些属性的值(通常是动态的);
     3,它的类的行为(从实现者的角度看);
     3,它的公开接口(从用户的角度看).

2.1 所有数据都应该隐藏在它所在的类内部.
    考虑最简单的点Point类(X,Y),再考虑可能点的实现是用的极坐标,那么是否该领悟到这一点了?

2.2,类的使用者必须依赖类的公共接口,但类不能依赖它的使用者.
    房子可以依赖闹钟,但是闹钟不能依赖房子,否则这个闹钟就不能放到别的地方了 2.3,尽量减少类的的方法的数量
    几年前,部分人所提倡的原则与此正好相反,他们认为凡是能想到的,将来用户可能都能用上.
    那么既然如此,那么你一定喜欢我的链表类,它的公共接口有4000个.（这里我第一次大笑) 2.4，实现所有类都能理解的最基本公共接口
    如：拷贝操作（深拷贝和浅拷贝），相等性判断，正确输出内容（打印），从字符串解析等 2.5,不要把实现细节放到类的公共接口
    目的是降低使用者的复杂度 2.6,用户不感兴趣的或无法使用的内容不要放到类的公共接口
   与2.5类似的 2.7,类之间应该零耦合,或者只有导出耦合关系.
   即:一个类要么同另一个类豪无关系,要么只使用另一个类的公共接口中的操作.
   低耦合,高内聚原则
   耦合:衡量两个类之间的关系.
   类聚:衡量类的实现,高类聚的最理想状态是:类的所有方法都使用了其所有字段或属性,不存在一半方法使用了这一半属性或字段,而另一半方法使用了另外一半的属性或字段.
    如果是这样,那这个类本身就应该被劈开为两个类. 2.8,类应当只表示一个关键抽象,反之亦然.
   如果一个关键抽象被表示为多个类,则表明设计者把这个关键抽象的每个功能表示为一个类了.
   反之,表明这个类表示了多个关键抽象,导致庞大复杂的类,还不好用(因为每次使用都牵扯到两个关键抽象概念) 2.9,把相关的数据和行为集中放置
    否则为了满足单一的需求变更,而不得不在两个或更多的地方进行修改 2.10,把不相关的信息放到另一个类中
   高类聚的原则 2.11,确保抽象的是类,而不是对象
   "父亲"和"母亲"是不是类,还是某个"人"的对象?要看具体应用是否区分了这两者,如果没有区分,则表示的是对象,否则就是类

OOD沉思录 之 继承

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

经典故事:

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