设计原则和设计模式

原则是在模式之下，比模式更抽象(模式是解决方案层面上)，原则是一种指导思想，更难理解。

SOLD原则

1、单一原则

一个类只有一个引起变化的原因；

职责-设计类时，关注职责；如果多于一个动机去改变这个类，那就不是单一职责。

克制一个类中写多个职责

软件设计更多关注的是职责和相互分离

2、开闭原则ocp

功能对修改关闭，多扩展开放

原则实现途径：策略模式(横向扩展)、模板模式（纵向扩展）、桥接模式

关键是抽象；

OOD核心

开发人员应该仅仅对程序中呈现出频繁变化的部分做出抽象

拒绝不成熟的抽象和抽象本身一样重要

3、里式替换

继承的时候，子类替换基类

子类型可替换才可使基类类型在无需改变的情况下就可以做拓展

违反情况：

派生类退化

派生类抛出异常

里式替换原则可以把基类和子类概况为can do，就是父类有哪些行为，子类也能实现这些行为。

两个特征：

• 宽进

子类的传参，必须在父类的传参上扩展，不能修改父类的传参

• 严出

父类经过一系列逻辑，得到一个输出；子类在父类处理逻辑上增加了逻辑，得到的输出小于父类的输出

4、依赖倒置

高层模块不应该依赖于底层模块；二者应该依赖抽象

抽象不应该依赖细节，细节依赖抽象

白话理解：我上游需要什么接口(抽象)，你下游去实现。

好处：面向接口编程，上层更稳当

例子：中台提供接口，我们用；一旦中台逻辑变了，它只需要改自己的业务即可；如果不是依赖的接口api，则下游服务需要改变

如果查询的依赖关系是倒置的，则是面向对象的设计，否则是过程化的设计；

5、接口隔离原则

不应该强迫客户依赖于他们不用的方法

如果类的接口不是内聚的，那就表示该类具有胖接口