序

学习过好多遍设计模式。感觉还是没学会。面试啥的又说不出来。

这是最后一次了。忘了并不代表不会。 知道个大概就行了

为啥要学设计模式：
1：阅读源代码的时候，知道是啥设计模式，就更容易看懂。
2：为了写出好的容易扩展的代码。应对 各种 变化。简单。

设计模式有指导原则。设计模式一般都是遵循设计原则的。
面向对象的原则：SOLID

• S：SRP
  单一职责原则：一个类最好只做一件事。这样修改此类的时候影响小。也容易了解类。小类小方法。人的大脑更容易处理。
• O: OCP
  开闭原则：only append,not update. 对扩展开放。对修改关闭。在一个项目上写代码。我们肯定希望的是只是增加代码，而不是在原来的代码上修改（不是自己写的。要修改就很痛苦，也容易出错）。好的设计模式就应该这样。但是呢，工作中在原来的代码上修改也是不可避免的。原则毕竟是理想主义。现实主义还是得修修补补的。
• L:
  里氏替换原则：子类尽量不要修改父类的方法。这样子类替换父类的时候。一般就不会出错了。
• I:IRP
  接口隔离原则：接口也是要保持高内聚 低耦合。不要把过多的接口方法放在一个接口里。这样实现接口的时候就很可能出现冗余。
• D：DIP
  依赖反转原则：这个以前学习spring框架的时候就没理解。说的很抽象。其实就是我们运行代码的时候，实际依赖的是具体的子类，但是写代码的时候我们要依赖的是子类的抽象，也就是父类。所以就是反转了。从子类反转到父类了。这样的好处就是解耦和统一抽象。容易替换不同的子类。抽象也就是定义接口，定义规范。我们依赖的是规范就不容易乱。
  依赖翻转还有相关的就是控制翻转（Inversion Of Control）。这里的反转。反转的是我们创建对象。比如。没有spring这种IOC框架的时候。对象的创建是我们自己写代码创建出来的。现在创建对象交给框架了。反转点在这。我们不关注创建。只关注具体的业务实现。

DIP和IOC都是设计原则。根据这俩个设计原则有了 DI(依赖注入是设计模式）。IOC容器框架就是DI的具体实现。
DI就是对象之间的关系我们只需要注解就直接拥有了。框架根据 构造方法、属性、方法注入某个对象到当前对象。

分层原则：一个层只关注一件事，然后只和它的上下层交互。各司其职。
简单原则：简单的实现复杂的功能。我们的大脑太次了。代码大部分是来阅读的。
分离原则：复杂的问题简化简化再简化。
契约原则：约定大于俗称。计算机发展到现在了，该有一定的模式，让我们程序员有共同的默契。知道哪些配置 哪些流程就该是这样的。

设计模式之 创建型

设计模式主要分为三大类：
创建型：主要解决如何创建对象。
结构性：对线之间的关系应该如何处理。是你继承我，还是我组合你。是依赖你的抽象等等。
行为型：主要是关于方法的处理。各种方法应该如何封装实现。

单例模式

在整个进程 程序中。这个类只有一个对象。像个全局变量一样。从哪获取到都是唯一的。
首先要提供全局获取到该对象的方法。
经典实现的右 懒汉模式、饿汉模式、双重校验（多线程的情况下)、枚举、线程ThreadLocal(这里是每个线程有自己独立的实例，不是全局一个）

简单工厂、抽象工厂、工厂方法

就是把创建对象这个变化封装起来。由工厂负责。 客户端只需要调用工厂这个类就行。修改点就在这个工厂类。
简单工厂：只有一个工厂。一个静态方法创建几个很少的对象。有更新的时候要修改这个工厂类的方法。违反了开闭原则。
工厂方法：有很多个工厂。每个具体的工厂创建不同同类型的不同产品。新增产品就新增工厂就行。主要是定义了抽象工厂的创建产品的类方法。 类会及很多。 日志类框架就是
抽象工厂：也是有很多个工厂。一个工厂创建的不是一个产品。而是相关的一系列产品。

原型模式

根据现有的对象创建新的对象。对象比较复杂。java就用 浅克隆 +深克隆实现。

建造者模式

创建不同形式的复杂对象。 其实就是链式编程。每个buildPart方法都返回自己的实例对象。

设计模式 之 结构型

适配器模式

解决的问题场景：原有的类不能修改。但是与新的类的接口不适配。我们就写一个适配类，专门写一个新接口调用原有的类。

桥接模式

桥：连接的俩端。可以独立的变化。比如 形状+颜色。都可以独立的实现。然后组合起来。

组合模式

可以让单个对象和组合对象的处理方式保持一致。常用在树形结构。

装饰模式、代理模式

这2个模式一起说。是因为这2个看起来很像。就是专注度不一样
装饰模式：动态的增强原有类的功能。是纵向的。可以使用继承，组合。修改对象的行为
代理模式：需要控制对象的访问。权限、模拟。虚拟代理、远程代理、缓存代理。控制对象的访问。

门面模式：

就是把一些复杂的方法再用一个类封装下。门面上好调用。对子系统提供统一的接口。

享元模式

一个对象有内在状态+外在状态。要创建很多对象可以共享其不变的内在状态。来减少内存的使用。

设计模式 之 行为型

类行为：继承
对象行为：组合或聚合

访问者模式

允许在运行时将一个或多个操作应用于一组对象。将操作于对象结构分离。
扫描文件。解压文件。
文件都可能需要扫描。扩展对象。
使用多态的方式。资源文件就比较臃肿。
每种操作都独立写成一个类。新增操作就新增类。
参考这个讲的很好 https://blog.csdn.net/SunnyYoona/article/details/140938479

模板方法

定义一个算法框架。其中部分算法步骤延迟到子类实现。

策略模式

每个算法封装起来，可以互相替换。

状态模式

根据不同的状态可以执行不同的行为。 状态更新图要了解。 到了一定的状态只能执行一定的操作。比如订单。
一个状态一个类。

观察者模式

订阅-发布模式。就是一个对象的变化需要通知给订阅该对象的多个对象。并执行相应的操作。

备忘录模式

可以回退到 历史记录的某一个状态。undo操作。会创建一个备忘录对象。然后根据备忘录对象恢复。

中介者模式

对象之间网状结构更改为星型结构。

迭代器模式

经典的遍历。每个对象的遍历行为。专门来创建一个迭代器对象。迭代器对象的hasNext() next()方法来遍历。统一美。

解释器模式

了解。自定义配置规则。

命令模式

请求中封装多个参数。请求封装为对象。一个请求就是一个对象。
请求和执行进行了解耦。

责任链模式

就是一个请求需要多个过滤审批操作。我们只关注和我们对接的。比如请假我只需要提交电子流给我们的PM.然后我们的PM再一个一个请求到上面的领导。直到能给我批准结束。
如果是一天假。PM就可以操作审批通过。如果是3天假。就得HRBP了。
当前责任对象会设置下一位。

总结

设计模式。有好有害。一般是有更多的抽象 + 封装 来应对 变化。让新增扩展 不更改更多的类。
设计的时候。要知道哪些是变化点。应不应该封装成一个新的类。
让系统变得更加复杂。好扩展。解耦。