1.1 单一职责原则
Single Responsibility Principle
建议：
接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化
1.2 里氏替换原则
Liskov Substitution Pronciple
定义：
只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常。
规范：
- 子类必须完全实现父类的方法
- 子类可以有自己的个性
- 覆盖或实现父类的方法时输入参数可以被放大
>参数不同相当于重载，不是覆写。
子类的参数范围如果比父类小，子类在没有覆写父类方法的前提下（将父类换为子类），子类方法可以被执行
- 覆写或实现父类的方法时输出结果可以被缩小
>如果是覆写，子类的输出结果应 <= 父类的输出结果
如果是重载，要求子类的输入参数宽于或等于父类的输入参数，也就是当将用父类的地方换为子类。这个方法也不会被调用。
建议：
采用里氏替换时，尽量避免子类的“个性”，一旦子类有“个性”，这个子类和父类之间的关系就很难调和了，把子类当做父类使用，自乐你的“个性”被抹杀——委屈了点；把子类单独作为一个业务来使用，则会让代码见的耦合关系变得扑朔迷迷离——缺乏类替换的标准。
1.3 依赖倒置原则
Dependence Inversioin Principle
含义：
- 高层模块不应该依赖低层模块，两者都应该依赖其抽象
- 抽象不应该依赖细节
- 细节应该依赖抽象
抽象：接口或抽象类。 细节：实现类
依赖的三种写法：
1、构造函数传递依赖对象
2、Setter方法传递依赖对象
3、接口声明依赖对象
建议：
依赖倒置原则的本质就是通过抽象（接口或抽象类）使个各类或模块的实现彼此独立，互不影响，实现模块间的松耦合。
- 每个类尽量都有接口或抽象类，或者抽象类和接口
基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置
- 变量的表面类型尽量是接口或者抽象类
注意Utils工具类和 java实现类的clone方法
- 任何类都不应该从具体类派生
类的继承层数尽量少
- 尽量不要覆写基类的方法
如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要再覆写。类间的依赖是抽象，覆写了抽象类的具体方法，对依赖的稳定性会有一定影响。
- 结合里氏替换原则使用
规则：接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化
1.4、接口隔离原则
Interface Segregation Principle
Java接口的种类：
- 实例接口（Object Interface）：Person zhangSan = new Person()； Person类就是zhangSan的接口
- 类接口（Class Interface）：用interface定义的接口
定义：
- 第1种：客户端不应该依赖它不需要的接口
- 第2种：类间的依赖关系应该建立在最小的接口上
概括：
接口尽量细化，同时接口中的方法尽量减少。与单一职责的区别：审视角度不同，单一职责要求的是类和接口职责单一，注重的职责，这是业务逻辑上的划分；接口隔离要求接口方法尽量少。职责相同，访问模块不同：尽量使用多个专门的接口，每个不同模块对应不同的接口。
建议：
- 一个接口只服务于一个子模块或业务逻辑
- 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法
- 已经被污染了的接口，尽量去修改，若变更风险较大，则采取适配器模式进行转化处理。
- 了解环境，拒绝盲从。
根据经验和常识决定接口的粒度大小，接口粒度太小，导致接口数据剧增，开发人员呛死在接口的海洋里；接口粒度太大，灵活性降低，无法提供定制服务，给整个项目带来无法预料的风险。
1.5、迪米特法则
Law of Demeter ，也称为最少知识原则（Least Knowedge Principle）
定义：
一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少
四层含义：
- 只和朋友交流
- 朋友间也是有距离的
- 是自己的就是自己的
有这样一个方法：放在本类中可以，放在其他类中也没错，那怎么去衡量呢？
如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放在本类中。 - 谨慎使用Serializable
VO：value object
建议：
- 迪米特法则的核心观念就是类间的解耦，弱耦合，只有弱耦合后，类的复用率才可以提高。其要求的结果就是产生了大量的中转或跳转类，导致系统复杂性提高。
- 在实际应用中，如果一个类跳转两次以上高才能访问到另一个类，就需要进行重构了。因为一个系统的成功不仅仅是一个标准或是原则就能够决定的，有非常多的因素。跳转次数越多，系统越复杂，维护就越困难，所以只要跳转不超过两次都是可以忍受的
- 迪米特法则要求类间的解耦，但解耦是有限度的。
1.6、开闭原则
Open Closed Principle
定义：
一个软件实体，如类、模块和函数 应该对扩展开发，对修改关闭
如何使用：
** 1. 抽象约束 **
抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放。其包含三层含义：
1.1. 通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；
1.2.参数类型、引用对象尽量使用接口或抽象类，而不是实现类；
1.3.抽象层尽量保持稳定，一旦确定即不允许修改。
** 2. 元数据控制模块行为 **
元数据：用来描述环境和数据的数据，通俗地说就是配置参数。参数可以从文件中获得，也可以从数据库中获得
** 3. 指定项目章程 **
约定优于配置
** 4. 封装变化 **
- a、将相同的变化封装到一个接口或抽象类中
- b、将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。
- 封装变化：也就是受保护的变化（protected variations），找出预计有变化或不稳定的点，我们为这些变化点创建稳定的接口，准确地讲是封装可能发生的变化，一旦预测到有变化，就可以进行封装。
