设计模式的六大原则有：
Single Responsibility Principle：单一职责原则
Open Closed Principle：开闭原则
Liskov Substitution Principle：里氏替换原则
Law of Demeter：迪米特法则
Interface Segregation Principle：接口隔离原则
Dependence Inversion Principle：依赖倒置原则
SRP 单一职责原则
单一原则就是一个类只负责完成一个职责或者功能，也就是说不要设计大而全的类，要设计粒度小，功能单一的类，换个角度来讲，如果有个类包含了两个或者两个以上业务不相干的功能，那我们就说它职责不单一，应该将它拆分成职能更加单一，粒度更细的类
比如微服务中的在线教室服务ClassroomService，既包含教室信息功能，又包含信令功能或者包含行为牌功能，这样就违背了单一职责原则，我们需要将它拆分成在线教室服务ClassroomService、信令服务SignService、行为牌服务CardService
开闭原则：对扩展开放，对修改关闭
开闭原则就是添加一个新的功能，应该在已有代码基础上扩展代码，而不是直接修改已有代码，比如新增模块、类、方法等，具体实现类似于面向接口编程
比如:我们之前是通过Kafka来发送异步消息，突然有一天总监要我们将Kafka或者RocketMQ替换成公司自研的VKMQ，我们应该定义抽象一个ICommonMessage,所有的上层系统都依赖ICommonMessage，这样我们只需要新增一个VKMQ implement ICommonMessage 就可以了 而不是直接修改以前的 kafka、RocketMQ发送消息的代码
之前做databus实现数据同步-数据双中心的时候，刚开始要求将阿里云mysql里面的数据同步到腾讯云mongodb中，我们实现了MongoTransfer类，后来又增加扩展同步到腾讯云mysql数据库中，此时我们只需要新增一个MysqlTransfer类来同步mysql数据库，而不是在原有的MongoTransfer类中进行修改
里氏替换法则
跟多态很像
多态是不管父类如何实现，子类实现的越多样越好，越多态越好
里氏替代法则是遵行协议约定的 子类函数的入参 返回需要保持一致
举个例子:1、比如父类seach()方法中如果参数错误，我们约定返回null
子类seach方法实现的时候，如果参数错误返回的是抛异常
2、父类search方法返回结果是按照主键id 自增排序，子类返回结果是按照修改时间 排序
这些情况都不满足里氏替换法则
接口隔离原则
接口隔离原则:客户端不应该强迫依赖它不需要的接口。
比如微服务中的用户服务，前端需要用户登录、注册、获取用户信息等等接口
这时候后台管理系统需要增加 用户删除、用户停用、根据用户手机号删除功能等接口
删除用户是非常谨慎的操作，我们只想仅限于后台管理系统，避免用户误操作
当然我们可以通过架构设计让后台管理员用户权限才能调用
另一方面我们可以通过代码设计的角度，将用户删除、用户停用、根据用户手机号删除功能等接口单独放到另外一个接口服务中，然后这个后台接口服务只提供给后台系统调用
在微服务中，将微服务拆分成外网服务、办公网服务、内网服务也是一种接口隔离原则的体现
依赖倒置原则
高层模块不要依赖低层模块。高层模块和低层模块应该通过抽象或者接口来互相依赖。
上面的例子上边的类显示的是Student类依赖了具体的教室，例如：Student类有一个learn(EnClassroom classroom) 方法，这样student就对具体的EnClassroom(英语教室) 产生了依赖，如果这个时候这学生想要进入MathClassroom(数学教室)、ChinaClassroom（语文教室）学习，就要修改Student类 增加learn(MathClassroom classroom) 、learn(ChinaClassroom classroom) 方法，并要引入（import）MathClassroom(数学教室)、ChinaClassroom（语文教室）的类， 这就不满足依赖倒置原则。
因此引入抽象接口IClassroom（教室接口），这样Student只需要依赖抽象接口IClassroom（教室接口）即可，至于Student到底选择哪个教室，就交给IOC容器，依赖注入即可，而且更具有扩展性。
迪米特法则
迪米特法则也叫最小知道原则，不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口
同样是实现“高内聚、低耦合”，单一职责是从自身提高的功能角度出发，迪米特法则是从类依赖关系的的角度出发，针对接口而非实现编程是使用者的角度，降低类与类之间的耦合。
