重学设计模式--读后总结篇，我理解的设计模式！！（二）

极力推荐小傅哥的重学设计模式！！！

一、二十三种设计模式
- 1.二十三种设计模式
- - 1.1 工厂方法模式
  - 1.2 抽象工厂模式
  - 1.3 建造者模式
  - 1.4 原型模式
  - 1.5 单例模式
  - 1.6 适配器模式
  - 1.7 桥接模式
  - 1.8 组合模式（没细品）
  - 1.9 装饰器模式（没细品）
  - 1.10 外观模式（没细品）
  - 1.11 享元模式
  - 1.12 代理模式（没有细品）
  - 1.13 责任链
  - 1.14 命令模式
  - 1.15 迭代器模式（没有细品）
  - 1.16 中介者模式（没有细品）
  - 1.17 备忘录模式（没有细品）
  - 1.18 观察者模式
  - 1.19 状态模式
  - 1.20 策略模式
  - 1.21 模板模式（没有细品）
  - 1.22 访问者模式（没有细品）
  - 1.23 解释器模式
- 2.设计模式的本质？主要是想解决什么样的问题？
- 3.如何不滥用设计模式？
- 4.思想的演变过程
二、参考：
三、更新日志

需要有一定设计模式基础的看，可以结合菜鸟教程等等的来一起看

一、二十三种设计模式

1.二十三种设计模式

随着互联网行业的发展，设计模式也在不多的变化、扩展。下面来介绍常用的二十三种设计模式!!!

1.1 工厂方法模式

将多段代码的共性行为抽象到接口中去定义，具体的实现由子类实现父类后去定义。最后，通过一个工厂类去根据传参来选择返回对应的实例化对象。
关键词： 工厂类一般带有Factory

1.2 抽象工厂模式

抽象工厂的本质是其它工厂类的抽象类，也就是将其他工厂类中的共性行为提取到了抽象工厂类
关键词： AbstractXXX
小傅哥在抽象工厂模式中是使用了抽象工厂的另一种实现，其中用到了代理、适配器、抽象工厂几个点，这里为CacheService的两种缓存模式实现加上了适配器，使其对应的方法与CacheService接口的方法对应，然后使用了动态代理，在代理实例调用方法时，方法调用被编码分派到调用处理程序的invoke方法。
可以将不同的缓存模式的适配器类看作为工厂的构建类，这些工厂类都存在有共性的getter、setter。
这些共性行为被抽象到了CacheService中，通过动态代理，在service调用的方法实际上调用的是适配器类中的方法。

        CacheService proxy_EGM = JDKProxy.getProxy(CacheServiceImpl.class, new EGMCacheAdapter());proxy_EGM.set("user_name_01", "小傅哥");String val01 = proxy_EGM.get("user_name_01");System.out.println("测试结果：" + val01);CacheService proxy_IIR = JDKProxy.getProxy(CacheServiceImpl.class, new IIRCacheAdapter());proxy_IIR.set("user_name_01", "小傅哥");String val02 = proxy_IIR.get("user_name_01");System.out.println("测试结果：" + val02);

1.3 建造者模式

日常生活中，装修房子会根据不同的场景、品牌、型号、价格等等组合形成了各式各样的装修风格（套餐A：现代简约，套餐B：轻奢田园，套餐C：欧式豪华）
一些基本物料不会变，而其组合经常变化的时候，就可以选择这样的构建者模式来构建代码。
关键词： Builder

1.4 原型模式

在考试中，每个考生得到的考卷题目大致相同，都是从同一个考题池中随机组合一套题目出来分发给所有考生进行考试，但是这样得到的题目，题序一样，容易引起作弊，而且还是不断地创建初始化统一对象。
使用原型模式：通过克隆方式创建复杂对象、也可以避免重复做初始化操作、不需要与类中所属的其他类耦合等。但也有一些缺点如果对象中包括了循环引用的克隆，以及类中深度使用对象的克隆，都会使此模式变得异常麻烦。（在重写的克隆方法中进行乱序）
关键词： 实现了Cloneable

1.5 单例模式

每次拿到或者创建获得的都是同一个实例
例如：Spring中的通过@Autowird自动注入获取的对象也是单例模式的一种体现（设定的Bean注入模式是单例），其底层是通过Bean的注入模式去决定，单例模式是将new创建的实例放入容器，每次拿到的都是这个实例对象，原型模式的话就是把创建类的Class对象放入容器，每次拿都是调用这个Class.newInstance
推荐使用枚举单例模式
这种方式解决了最主要的；线程安全、自由串行化、单一实例。
关键词： enum

1.6 适配器模式

为存在共性行为但是调用方法不同的类创建适配器接口，适配器的实现类实际上调用的是原对象的对应方法。
接口已经做了统一的包装，外部使用时候就不需要关心内部的具体逻辑了。而且在调用的时候只需要传入统一的参数即可，这样就满足了适配的作用。
关键词： Adapter

1.7 桥接模式

桥接模式的主要作用就是通过将抽象部分与实现部分分离，把多种可匹配的使用进行组合。说白了核心实现也就是在A类中含有B类接口，通过构造函数传递B类的实现，这个B类就是设计的桥。
通过模拟微信与支付宝两个支付渠道在不同的支付模式下，刷脸、指纹、密码，的组合从而体现了桥接模式的在这类场景中的合理运用。
在支付方式中桥接了指纹支付、人脸支付
Pay zfbPay = new ZfbPay(new PayFingerprintMode());
关键词： Bridge/在初始化时传入其它对象作为本类执行方法的判断

1.8 组合模式（没细品）

组合模式的主要解决的是一系列简单逻辑节点或者扩展的复杂逻辑节点在不同结构的组织下，对于外部的调用是仍然可以非常简单的。

1.9 装饰器模式（没细品）

new BufferedReader(new FileReader(""));，这段代码你是否熟悉，相信学习java开发到字节流、字符流、文件流的内容时都见到了这样的代码，一层嵌套一层，一层嵌套一层，字节流转字符流等等，而这样方式的使用就是装饰器模式的一种体现。

1.10 外观模式（没细品）

外观模式也叫门面模式，主要解决的是降低调用方的使用接口的复杂逻辑组合。这样调用方与实际的接口提供方提供方提供了一个中间层，用于包装逻辑提供API接口。有些时候外观模式也被用在中间件层，对服务中的通用性复杂逻辑进行中间件层包装，让使用方可以只关心业务开发。

1.11 享元模式

享元模式，主要在于共享通用对象，减少内存的使用，提升系统的访问效率。 而这部分共享对象通常比较耗费内存或者需要查询大量接口或者使用数据库资源，因此统一抽离作为共享对象使用。
通过各种方式将可重用的数据进行缓存整个对象，减少内存占用和查询次数
在活动秒杀的场景之下，活动的信息是不不变的，只有商品的库存在发生变换，每次从数据库种获取到的活动信息对象除了库存信息其它都是一致的，这个时候可以使用享元模式，将重复的部分缓存起来重复使用，这里使用了项元工厂，用map在初始化时从数据库缓存活动信息，库存信息由之后从redis种获取后拼接到活动信息中。

1.12 代理模式（没有细品）

代理模式有点像老大和小弟，也有点像分销商。主要解决的是问题是为某些资源的访问、对象的类的易用操作上提供方便使用的代理服务。而这种设计思想的模式经常会出现在我们的系统中，或者你用到过的组件中，它们都提供给你一种非常简单易用的方式控制原本你需要编写很多代码的进行使用的服务类。
大概就是：实现了代理之后的一些列封装设计。
代理模式的讲解我们采用了开发一个关于mybatis-spring中间件中部分核心功能来体现代理模式的强大之处，所以涉及到了一些关于代理类的创建以及spring中bean的注册这些知识点，可能在平常的业务开发中都是很少用到的，但是在中间件开发中确实非常常见的操作。
代理模式除了开发中间件外还可以是对服务的包装，物联网组件等等，让复杂的各项服务变为轻量级调用、缓存使用。你可以理解为你家里的电灯开关，我们不能操作220v电线的人肉连接，但是可以使用开关，避免触电。
代理模式的设计方式可以让代码更加整洁、干净易于维护，虽然在这部分开发中额外增加了很多类也包括了自己处理bean的注册等，但是这样的中间件复用性极高也更加智能，可以非常方便的扩展到各个服务应用中。

1.13 责任链

这个我熟，比较常用也比较简单的一种，责任链模式的核心是解决一组服务中的先后执行处理关系，就有点像你没钱花了，需要家庭财务支出审批，10块钱以下找闺女审批，100块钱先闺女审批在媳妇审批。你可以理解想象成当你要跳槽的时候被安排的明明白白的被各个领导签字放行。

责任链模式1.核心思想链式有序执行，每一节点的执行都依赖于上一级节点的执行结果。2.结构划分抽象父类：Action属性：Action action用于存放指向下一结点的对象引用抽象方法：start()由实现的子类去定义当前节点具体的逻辑实现方法：action()结点执行判断分支，成功-进入下一节点的do执行，失败-执行完毕返回子类：openDeviceAction（等等多个子类节点）重写start（）方法实现具体的逻辑组装执行类：Call（封装好执行行为顺序、逻辑，哪里需要哪里用）创建需要用到的节点，用setNext指定下一节点（执行顺序），调用第一个节点的action（）启动3.特点、关键词链表数据结构，责任链的本质就是一种链表数据结构，通过节点指向下一节点来确保节点的执行顺序，（Next、Node）

1.14 命令模式

命令场景的核心的逻辑是调用方与不需要去关心具体的逻辑实现，在这个场景中也就是点餐人员只需要把需要点的各种菜系交个小二就可以，小二再把各项菜品交给各个厨师进行烹饪。也就是点餐人员不需要跟各个厨师交流，只需要在统一的环境里下达命令就可以。
其实我的理解就是这种模式就是一种行为的封装，下次想要用到这部分的代码就直接调方法，而不是写一长串的一条条代码。
这里的特点就是被调用方及行为被抽象到接口中了，在调用方可以利用多态调用用过被调用方的具体实现及行为方法
命令模式的使用场景需要分为三个比较大的块；命令、实现、调用者，而这三块内容的拆分也是选择适合场景的关键因素，经过这样的拆分可以让逻辑具备单一职责的性质，便于扩展。

1.15 迭代器模式（没有细品）

迭代器模式，常见的就是我们日常使用的iterator遍历。虽然这个设计模式在我们的实际业务开发中的场景并不多，但却几乎每天都要使用jdk为我们提供的list集合遍历。另外增强的for循环虽然是循环输出数据，但是他不是迭代器模式。迭代器模式的特点是实现Iterable接口，通过next的方式获取集合元素，同时具备对元素的删除等操作。而增强的for循环是不可以的。另外，迭代过程中是不允许删除元素的。
这种设计模式的优点是可以让我们以相同的方式，遍历不同的数据结构元素，这些数据结构包括；数组、链表、树等，而用户在使用遍历的时候并不需要去关心每一种数据结构的遍历处理逻辑，从让使用变得统一易用。

1.16 中介者模式（没有细品）

中介者模式要解决的就是复杂功能应用之间的重复调用，在这中间添加一层中介者包装服务，对外提供简单、通用、易扩展的服务能力。
这样的设计模式几乎在我们日常生活和实际业务开发中都会见到，例如；飞机