设计模式之设计原则

单一职责原则 SRP 一个类或者模块只负责完成一种职责 现在微服务还有模块的分层 就是基于这个原则

单一职责，我个人认为单一职责是一个分工合作，对于模块来说做的更精准不需要考虑其他的模块的信息，做到了一个模块小而精，对于整理来说松耦合

里氏替换原则 LSP 多用组合 少用继承

1. 子类必须实现父类的抽象方法，但不得重写（覆盖）父类的非抽象（已实现）方法。

2. 子类中可以增加自己特有的方法当子类覆盖或实现父类的方法时，

3. 方法的前置条件（即方法的形参）要比- 父类方法的输入参数更宽松。(即只能重载不能重写)

4. 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

里氏替换原则 是基于子类对父类进行扩展，是对封装和多态的补充。因为封装和继承的要求有些复杂，所以里氏替换原则推荐我们使用组合少用继承

依赖倒置 DIP

1. 下层模块引入上层模块 改变原来自上而下的依赖方式

2. 类比假如你是一个演员，没有出名的时候，需要你自己去找合作。你出名以后，合作会自动找你，这种改变就叫做依赖倒置。

3. 不要面向具体的对象编程 这样会造成较大的耦合。要面向抽象的接口编程

依赖倒置就是说从我去寻找他们变成他们需要我， 对上层模块进行统一管理

接口隔离原则建立单一接口

1. 接口尽量细化，接口中的方法尽量少

   1. 接口要尽量小
   2. 接口要高内聚
   3. 定制服务

2. 以人举例，如果你要实现一个人的接口，只需要提供一个基础的人作为接口 然后具体的人添加不同的具体的功能

3. 比如一个接口下，同时是实现了新增和修改两个接口 这就违反了接口隔离原则

简单说就是一个接口实现一个功能

迪米特法则 最少知识原则 （只是买台咖啡机，竟然要学习咖啡的工作原理）

1. 只和你的密友对话 感觉外观模式就是基于迪米特法则

2. 我付完款去下单 我直接调用下单接口就应该可以实现下单功能 不需要了解下单功能里的详情

开闭原则

1. 类、方法、模块应该对扩展开放 对修改关闭

2. 添加一个功能应该是在已有的代码基础上进行扩展 而不是修改已有代码