设计模式是软件设计中常见问题的典型解决方案。它们就像能根据需求进行调整的预制蓝图， 可用于解决代码中反复出现的设计问题。
-
设计模式相对比较软性，是对解决某类场景问题的高层描述；
-
根据使用人的不同应用的也不同
-
只是一种思想，没有好坏之分，只有更适合；
-
我们应该关注要达到什么样的目的，怎么更加灵活的做到；
-
软件中唯一不变的是变化，设计模式让我们想各种方法屏蔽这种变化；
设计模式包含：
-
意图：简单描述问题和解决方案
-
动机：进一步解释问题并说明模式会如何提供解决方案；
-
结构：如何将软件结构组装起来并形成关系
设计原则：
SOLID原则 solid->稳定的
-
S Single Responsibility Principle: 单一职责原则
-
O open closed Principle: 开闭原则
-
L Liskov Substritution Principle: 里氏替换原则
-
I Interface Segegation Principle: 接口隔离原则
-
D Dependence inversion Principle: 依赖倒置原则
内聚：从功能相关来谈，主张高内聚，把功能高度相似的代码内聚到一起，方便统一维护；耦合：从功能无关来谈，主张低耦合。不要把明显无关的功能随意结合，以降低耦合性；在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动也不会或很少导致依赖类的代码改动；
单一职责原则 SRP（Single Responsibility Principle）
定义：一个类或者模块只负责完成一个功能。特点：
-
模块可以看作是类的抽象或者是聚合；
-
单一，只是在特定的场景下单一， 比如一个类单一，一个模块单一
-
单一尽可能设计的粒度小、功能单一
-
比如下单功能，可能涉及到下单，查询用户，查询地址，优惠券使用，每一点都是单一功能，不要一写写一坨；
实现目的：从自身角度考虑代码的高内聚、低耦合、提高代码的复用性、可读性、可维护性；
开闭原则 OCP （Open Closed Principle）
定义：对扩展开放，对修改关闭
特点：
-
添加新功能，在已有的代码基础上扩展代码（新增类、方法等），而非修改已有的代码
-
开闭原则并不是完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发；
-
同样的代码改动，在粗代码力度下，可以被被认定为修改，在细代码力度下，被认为是扩展；
-
提高代码扩展性的方法：多态、依赖注入、面向接口编程、适配、装饰、策略、模板、责任链、状态等
-
对扩展开放是未了应对软件的变化，对修改关闭是未了保证系统的稳定性，最后是未了让系统具备可扩展性（弹性）；
-
也不要一味的遵循开闭，导致代码的复杂度过度的增加；
-
开闭也减少了测试的复杂度；
实现目的：基于自身考虑代码的结构，解决代码的扩展性的问题
里氏替换原则 LSP Liskov Substitution Principle
定义：值对象能够替换程序中的父对象出现的任何地方，并保证原来程序的逻辑以及正确性不变。也就是说在子类实现父类的时候，要遵守父类的行为约定。子类可以改变内部的实现逻辑，但不能改变函数原有的行为约定（比如子类冒出一个父类未知的异常，或者状态码）
特点：
-
子类能替换父类出现的任何地方；
-
子类必须严格遵守父类的行为约定（新增的异常、状态码，只有在子类逻辑中触发，不能在父类中触发），以保证原有程序的正确性；
-
里氏替换原则和多态有点类似
-
多态是面向对象的一大特性，也是面向对象的一种语法；
-
多态是一种代码实现的思路
-
里氏替换原则是一种设计原则，用来指导继承关系中子类应该如何设计；
实现目的：改进已有实现（对父类的代码进行增强）、指导程序开发（类的组织关系）、改进抽象设计；
接口隔离原则 ISP Interface Segregation Principle
定义：调用者（使用者）不应该被强迫依赖它不需要的接口。三种场景：
-
一组API接口集合：比如dubbo提供的Api，一个接口内可能有好几个方法，我们只需要使用其中一个；
-
单个接口：比如在我们的系统有一些聚合接口，提供给外部，有新的需求时，可能只用其中一个字段，就直接调接口取了；
-
OOP中的接口概念：主张多继承，不要把一坨都写到一个接口里；
特点：
-
一个类对另外一个类的依赖应当是建立在最小的接口上；
-
客户端不应该依赖它不需要的接口方法/功能；
-
接口实现尽可能的单一，不要依赖不需要的；
-
接口隔离和单一职责的区别：
-
单一职责是针对的模块、类、接口的设计；
-
接口隔离原则提供了一种判断接口的职责是否单一的标准；
实现目的：基于调用者考虑，低耦合、确保最小依赖/调用/使用；
依赖倒置原则
定义：高层模块不要依赖低层模块，高层模块和低层模块应该通过抽象来相互依赖。
在之前的DDD应用框架中，基础设施层就依赖倒置了domain层；
特点：
-
高层不依赖低层模块，共同依赖同一个抽象
-
抽象不关注具体的实现细节，具体实现细节依赖于抽象；
实现目的：指导框架层面的设计
迪米特法则 LOD Law of Demeter
定义：不该有直接依赖关系的类之间，不要有依赖，有依赖关系的类之间，尽量只依赖必要的接口；
特点：
-
不该有直接依赖关系的，不要有依赖；
-
有依赖的，尽量只依赖必要的接口；
实现目的：基于类关系，高内聚、松耦合
DRY 原则 Don’t Repeat Yourself
定义：不要写重复的代码。
特点：
-
代码复用
-
减少代码藕合
-
满足单一职责
-
模块化
-
业务与非业务逻辑分离
-
继承、多态、抽象、封装
-
应用模板等设计模式将功能拆解为原子方法；
实现目的：代码复用
KISS 原则
定义：尽可能的保持简单
-
Keep It Simple and Stupid.
-
Keep It Short and Simple.
-
Keep It Simple and Straightforward.
特点：
-
代码足够简单，意味着通俗易懂，bug难隐藏
-
不要使用同事不懂的技术来实现代码
-
不要重复造轮子
-
不要过度优化
实现目的：保持代码的可读性和维护性