设计模式

六大设计原则

1、单一职责原则

一个类应该只有一个引起它变化的原因,一个职责。

优点：

类的复杂性降低，实现什么职责都有清晰明确的定义;

可读性提高，复杂性降低，那当然可读性提高了;

可维护性提高，可读性提高，那当然更容易维护了;

变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修 改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大 的帮助。

2、里氏替换原则

所有引用基类的地方必须能透明地使用其子类的 对象。

注意：

在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明 类的设计已经违背了LSP原则。

如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发 生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

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

重点：

1.子类必须完全实现父类的方法；

2.子类可以有自己的个性；

3.覆盖或者实现父类的方法时，输入参数可以被放大；

4.覆盖或者实现父类的方法时，输出参数可以被缩小；

目的

采用里氏替换原则的目的就是增强程序的健壮性，版本升级时也可以保持非常好的兼容 性。即使增加子类，原有的子类还可以继续运行。在实际项目中，每个子类对应不同的业务 含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑，非常完美!

3、依赖倒转原则

要针对抽象层编程，而不要针对具体类编程。

• 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过 接口或抽象类产生的;

• 接口或抽象类不依赖于实现类;

• 实现类依赖接口或抽象类。

优点：

可以减少类间的耦合性；

提高系统的稳定性；

降低并行开发引起的风险；

提高代码的可读性和可维护性；

最佳实践：

• 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备；
• 变量的表面类型尽量是接口或者是抽象类；
• 任何类都不应该从具体的类派生
• 尽量不要覆写基类的方法；

依赖倒置的理解：

依赖正置就是类间的依赖是实实在在的实现类间的依赖，也就是面 向实现编程，这也是正常人的思维方式，我要开奔驰车就依赖奔驰车，我要使用笔记本电脑 就直接依赖笔记本电脑，而编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是 有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思 维中的事物间的依赖，“倒置”就是从这里产生的。

接口隔离原则

使用多个专门的接口来取代一个统一的接口。

开闭原则

软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能。

所以我们在编码的期间，需要充分考虑以后系统的的拓展性、规范接口、依赖抽象，这样才能在以后需要拓展的时候，非常方便的实现拓展的效果，而不必去修改祖传代码。

迪米特法则（最少知道原则）

一个实体应当尽量少地与其他实体之间发生相互作用。

参考blog:juejin.cn/post/684668…

阅读书籍：《设计模式之禅》