设计模式简述（一）设计原则

6大基本设计原则

单一职责原则

一个接口、一个类、一个方法的功能尽量保证原子性。
至于这个度自己把握，没有绝对的标准。

• 通常可以将同一类、同一业务、同一模块或紧密相关的逻辑归到一个接口、一个类或一个方法中

依赖倒置原则

• 实现类依赖抽象，抽象不应依赖实现类
• 高层模块依赖低层模块，低层模块不应依赖高层模块

依赖传递方式

• 构造方法注入：使用构造方法参数注入依赖（依赖相对固定不变的情况使用）
• set方法注入：使用set方法动态注入依赖（依赖会动态变化的情况使用）
• 接口注入（又叫参数注入）：将依赖声明到方法的参数中，在每次实际调用时传入依赖
  注意，依赖要声明为抽象（抽象类或接口）

里氏替换原则

• 子类不应覆盖（方法签名完全一样才为覆盖或重写） 父类已经实现的方法
• 子类若要与父类方法构成重载（方法名相同、参数列表不同），这里要尤其注意，子类参数范围不能小于父类，返回值范围不能大于父类，否则就无法满足里氏替换原则。

接口隔离原则

• 接口功能尽量简单
• 接口尽量高内聚（减少外部依赖）

迪米特法则

这个原则是描述的类间的耦合关系。

一个类只和直接相关的类耦合，对于直接相关的定义限于：类成员、方法参数、方法返回值
也就是说在方法内部出现了非基础依赖中类（通常指的是开发者自定义的业务类），则可能违反该原则。在实际开发中要完全遵守很难，可以尽量往这上面靠，能不依赖其他自定义类尽量不依赖。

开闭原则

开闭原则更像是一种抽象的声明，是对前面几个具体原则的一个抽象。

对扩展开放，对修改关闭
简单来说，就是通过扩展来应对变化，而不是修改原有的代码。

要实现开闭原则，必须满足里氏替换原则，以及依赖倒置等等都是前提条件，因此强烈建议业务类要使用抽象进行约束，以便于后续扩展

在设计阶段，

• 可以将稳定的和大概率会发生变化的点进行分离
• 对于不稳定会发生变化点再细分到不同抽象中
  如此一来，每个点发生变化不会影响其他点