概括23种设计模式

创建型：对于对象的实例化进行解耦

单例

有且只能有一个实例，且全局可访问。注意懒汉(提前实例化但是浪费内存)和饿汉(延后实例化但是要处理线程安全问题)的区别。

三个工厂(只有后两个属于GOF23种设计模式)

简单工厂

• 实现：
  定义一个产品接口和诸多实现了该接口的具体产品类
  定义一个工厂类，内含一个生产产品的方法，通过传入的参数来判断实例化哪种产品并返回。

  即只有一个工厂，内置多个生产方法(或者多个if else)

• 使用案例：
  想获得加法操作对象，就向工厂类的生产产品方法传入字符+，返回new AddOperation()

工厂方法

• 实现
  也定义一个产品接口和诸多实现了该接口的具体产品类
  注意这里，定义的是工厂接口和诸多实现了该接口的具体工厂类，每个具体工厂类都有对应的生产产品的方法

  即有多个工厂，每个工厂都生产对应的产品

• 使用案例
  想获得加法操作对象，就调用AddFactory的getOperation方法，返回new AddOperation()

抽象工厂

• 实现
  相较于工厂方法，为了减少工厂的数量，让每个工厂都可以生产多种产品。
  如小米工厂生产小米手机和小米电脑、华为工厂生产华为手机和华为电脑。
• 使用案例
  新建小米工厂，调用mi.getPhone获得小米手机,调用mi.getComputer获得小米电脑。华为同理。

建造者

• 实现
  有零件类、工人类、机器类
  其实就是工人类封装了组装零件的细节，直接返回了机器对象
• 对比
  - 与工厂模式：工厂模式注重于对新建对象方式的解耦，其新建对象是一步完成的。而建造者模式是需要组装多个部件才能新建完成一个对象的，注重于这个组装的过程及组装顺序。

原型

• 实现
  其实就是使用了对象的拷贝取代了new，因为二者在效率上是有差异的。

结构型：

适配器

• 实现
  参考变压器、编译器等。变压器类继承220V电压类、实现变压器接口。5V变压器重写变压方法为转换为5V，10V变压器重写为转换为10V。

桥接

感觉图片会好理解一点
原本的继承关系，不同维度的属性通过层层继承实现

独立各维度的属性后如下

组合

• 实现
  定义叶节点类和非叶节点类，他们都继承节点抽象类，将数据以树形方式构建起来

装饰者

• 实现
  其实就是把被装饰的东西注入到有装饰方法的对象里，层层包装
• 使用案例

  奶茶 milkTea = new 奶茶()
  糖添加者 sugar = new 糖添加者(milkTea)
  芋圆添加者 yuYuan = new 芋圆添加者(sugar)
  布丁添加者 buDing = new 布丁添加者(yuYuan)
  sout(buDing)//加了糖、芋圆、布丁的奶茶
  1
  2
  3
  4
  5

外观

• 实现
  封装内部复杂细节(关乎到多个类、多个系统的"复杂"，而不只是过程的复杂)，对外提供简单接口

享元

• 实现
  享元即共享的元素，参考Java的常量池，将常用的对象用池子保存并管理，多次调用只会获得同一个对象。

代理

• 实现
  联想买房的场景，将买房者对象注入中介对象的属性中，让中介提出买房者的要求，接收卖房者的反馈，起到保护买房者的作用。

行为型

访问者TODO

没想明白，先放篇感觉可以的、别人的博客 设计模式之访问者模式

模板

• 实现
  思想上就是面向对象的继承，使用抽象类和子类继承实现就行

策略

• 实现
  其实就是将switch-case的各个case用多种策略类表示，这些策略类继承于一个策略基类，以方便修改，即替换对象而不是更改方法细节。

状态

• 实现
  如果类有状态属性的话，就可以让多种状态以多种状态类表示，对象变换状态就是注入新状态。

观察者

• 实现
  以师生为例，老师为被观察者，学生为观察者。老师有一个存储学生的集合，老师和学生都有一个进行操作的方法。老师进行操作时，还会调用集合内学生的操作方法。这样子看起来就是"老师一动，学生就动了"。

备忘录

• 实现
  在正常业务的基础上，定义记录类和记录者类，业务对象新增读取记录方法。在客户端，对于业务对象的每次操作，记录者类根据当前状态创建记录并进行存储和管理，业务对象想读取历史记录时，调用自己的读取记录方法，传入记录者类返回的记录对象即可。

中介者

• 实现
  参考消息队列。

迭代器

• 实现
  参考Java、C++的迭代器，即各集合提供统一接口、封装复杂细节

命令

• 实现
  有命令发送者、命令接收者、命令三个类
  命令对象保存了接收者对象，并有一个成员方法(例如excute)是调用了接收者处理该命令的方法
  发送者只负责调用excute
  这样子就保证了发送者和接收者的解耦，因为发送者无需知道接收者是谁，接收者是在新建命令对象时存储在命令中的，并且是由命令主动去让接收者使用自己的

责任链

• 实现
  联想到过滤器这东西，一层一层更密的筛子对混合物进行过滤。在代码实现上，每层过滤器都是一个类，且他们都保存了下一层过滤器的引用，以方便在自己这里过滤不了时将混合物送往下一层过滤器进行过滤。而混合物只需调用一次过滤操作就行，过滤的过程由过滤器们联动实现。

解释器(用得少、难理解、遂不概括)

收集了一下设计模式常见优缺点(自行对号入座吧)

优点

• 提高可复用性
• 提高可维护性
• 降低耦合度
• 降低代码复杂性
• 提高可读性
• 提高可扩展性
• 增强健壮性

缺点

• 类的数量增多，增加复杂性
• 系统更抽象，理解难度增加
• 修改成本增大
• 扩展困难
• 容易引入风险
• 请求处理速度变慢
• 客户端必须知晓细节并自行决策
• 增加了资源占用，如内存等