《设计模式之禅》读书笔记-1.0-六大设计原则

1.1 单一职责原则

Single Responsibility Principle

建议：

接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化

1.2 里氏替换原则

Liskov Substitution Pronciple

定义：

只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常。

规范：

1. 子类必须完全实现父类的方法
2. 子类可以有自己的个性
3. 覆盖或实现父类的方法时输入参数可以被放大

>参数不同相当于重载，不是覆写。    
子类的参数范围如果比父类小，子类在没有覆写父类方法的前提下（将父类换为子类），子类方法可以被执行

4. 覆写或实现父类的方法时输出结果可以被缩小

>如果是覆写，子类的输出结果应 <= 父类的输出结果
如果是重载，要求子类的输入参数宽于或等于父类的输入参数，也就是当将用父类的地方换为子类。这个方法也不会被调用。

建议：

采用里氏替换时，尽量避免子类的“个性”，一旦子类有“个性”，这个子类和父类之间的关系就很难调和了，把子类当做父类使用，自乐你的“个性”被抹杀——委屈了点；把子类单独作为一个业务来使用，则会让代码见的耦合关系变得扑朔迷迷离——缺乏类替换的标准。

1.3 依赖倒置原则

Dependence Inversioin Principle

含义：

1. 高层模块不应该依赖低层模块，两者都应该依赖其抽象
2. 抽象不应该依赖细节
3. 细节应该依赖抽象

抽象：接口或抽象类。 细节：实现类

依赖的三种写法：
1、构造函数传递依赖对象
2、Setter方法传递依赖对象
3、接口声明依赖对象

建议：

依赖倒置原则的本质就是通过抽象（接口或抽象类）使个各类或模块的实现彼此独立，互不影响，实现模块间的松耦合。

1. 每个类尽量都有接口或抽象类，或者抽象类和接口

   基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置

2. 变量的表面类型尽量是接口或者抽象类

   注意Utils工具类和 java实现类的clone方法

3. 任何类都不应该从具体类派生

   类的继承层数尽量少

4. 尽量不要覆写基类的方法

   如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要再覆写。类间的依赖是抽象，覆写了抽象类的具体方法，对依赖的稳定性会有一定影响。

5. 结合里氏替换原则使用

   规则：接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化

1.4、接口隔离原则

Interface Segregation Principle

Java接口的种类：

1. 实例接口（Object Interface）：Person zhangSan = new Person()； Person类就是zhangSan的接口
2. 类接口（Class Interface）：用interface定义的接口

定义：

1. 第1种：客户端不应该依赖它不需要的接口
2. 第2种：类间的依赖关系应该建立在最小的接口上

概括：

接口尽量细化，同时接口中的方法尽量减少。与单一职责的区别：审视角度不同，单一职责要求的是类和接口职责单一，注重的职责，这是业务逻辑上的划分；接口隔离要求接口方法尽量少。职责相同，访问模块不同：尽量使用多个专门的接口，每个不同模块对应不同的接口。

建议：

1. 一个接口只服务于一个子模块或业务逻辑
2. 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法
3. 已经被污染了的接口，尽量去修改，若变更风险较大，则采取适配器模式进行转化处理。
4. 了解环境，拒绝盲从。

根据经验和常识决定接口的粒度大小，接口粒度太小，导致接口数据剧增，开发人员呛死在接口的海洋里；接口粒度太大，灵活性降低，无法提供定制服务，给整个项目带来无法预料的风险。

1.5、迪米特法则

Law of Demeter ，也称为最少知识原则（Least Knowedge Principle）

定义：

一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少

四层含义：

1. 只和朋友交流
2. 朋友间也是有距离的
3. 是自己的就是自己的

   有这样一个方法：放在本类中可以，放在其他类中也没错，那怎么去衡量呢？
   如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放在本类中。

4. 谨慎使用Serializable

   VO：value object

建议：

1. 迪米特法则的核心观念就是类间的解耦，弱耦合，只有弱耦合后，类的复用率才可以提高。其要求的结果就是产生了大量的中转或跳转类，导致系统复杂性提高。
2. 在实际应用中，如果一个类跳转两次以上高才能访问到另一个类，就需要进行重构了。因为一个系统的成功不仅仅是一个标准或是原则就能够决定的，有非常多的因素。跳转次数越多，系统越复杂，维护就越困难，所以只要跳转不超过两次都是可以忍受的
3. 迪米特法则要求类间的解耦，但解耦是有限度的。

1.6、开闭原则

Open Closed Principle

定义：

一个软件实体，如类、模块和函数 应该对扩展开发，对修改关闭

如何使用：

** 1. 抽象约束 **
抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放。其包含三层含义：

1.1. 通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；
1.2.参数类型、引用对象尽量使用接口或抽象类，而不是实现类；
1.3.抽象层尽量保持稳定，一旦确定即不允许修改。

** 2. 元数据控制模块行为 **

元数据：用来描述环境和数据的数据，通俗地说就是配置参数。参数可以从文件中获得，也可以从数据库中获得

** 3. 指定项目章程 **

约定优于配置

** 4. 封装变化 **

• a、将相同的变化封装到一个接口或抽象类中

• b、将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。
• 封装变化：也就是受保护的变化（protected variations），找出预计有变化或不稳定的点，我们为这些变化点创建稳定的接口，准确地讲是封装可能发生的变化，一旦预测到有变化，就可以进行封装。