设计模式的笔记

我的笔记来自于图文并茂的设计模式在线书籍：https://refactoringguru.cn/design-patterns/catalog

设计模式不是银弹，不能解决所有问题，不要拿着锤子找钉子。

创建型

1、工厂方法，隐藏了构建的复杂逻辑，将相似的一些对象的构造放到一起。
2、抽象工厂是工厂方法的变体，抽象层次更高的工厂方法。家具工厂 -> 各种风格的家具工厂
3、生成器（builder）用于解决构造函数太复杂的情况，构造函数的参数多就会很难使用（例如grpc的server builder），解决了重叠构造函数的问题。并且用director这样一个角色来指导builder的做法。
4、原型模式用于复制比较复杂的对象，通常是值复制
5、单例：单例很像一个全局变量，但是是延迟创建，第一调用才会构造。

结构型

1、适配器，将一份数据、对象适配到一个不方便修改的接口上去，比如充电器转化器。
2、装饰器模式，能够方便的装饰/修饰一个基础功能，notify装饰成qqnotify，再装饰成为wechatnotify。如发送基础的数据装饰成压缩的数据，再装饰成压缩地、加密地数据。
3、代理模式，构建客户端代理，比如缓存客户端的请求，直接获取值，和装饰器比较像，装饰器是使得功能更加强大，代理模式是限制访问。
4、桥接模式，让gui能在linux和windows上不同实现
5、外观模式（facade），将复杂的多个子系统的接口实现简单话，我觉得很像工厂方法。比如函数签名convert(filename, format)，format提供不同的格式调用不同的子系统。
6、组合模式（composite），树状节点可以用组合模式，组合模式是箱子和各种小对象的组合，通过总的盒子像所有的小对象发布操作。
7、享元模式，将对象的变量分割成为内在状态和外在状态，内在状态是指对象中可以重复使用的，外在状态是指对象各自不同的成员变量。通常搭配工厂方法使用，工厂方法保存共享的池子。

行为型

1、责任链模式，让请求、数据沿着责任链传递，处理。和装饰器很像，但是责任链能够中断行为，装饰器最终会走到底。比如多级认证可以用责任链，而数据转换用装饰器。
2、命令模式，将多种执行接口抽象成命令，比如一个窗口的各种按钮，按钮可以抽象成为保存命令、取消命令、渲染命令等。
3、迭代器模式，隐藏了内部的数据结构实现细节，比如stl的迭代器
4、中介模式，多个复杂的同级的类需要在一起协作时，这些复杂类的相互调用。
5、备忘录模式，快照由对应需要产生快照的类产生，并且交由一个负责人类进行压栈保存，并且负责人类没有权限访问这个快照类。
6、观察者模式，订阅、发布的一个处理逻辑，解决客户不断检查和服务端广播的问题。
7、状态模式，和有限状态机关联，但是状态的实现通常是条件语句实现，如果逻辑变得复杂，那就会获得一个及其膨胀的if/else/switch语句。如果逻辑复杂并且重复代码多的话可以考虑每个类实现一个状态，在不同状态下的相同行为产生不同的动作。比如文章的草稿状态是可以反复编辑的，但是到了发布状态后就应该收回部分编辑权限。
8、策略模式，定义一系列算法， 并将每种算法分别放入独立的类中， 以使算法的对象能够相互替换。给定一个context，设定不同的策略，执行相同的函数，执行不同的算法。
9、模板模式，在基类中定义一个过程，由子类实现过程。可以将重复方法都提取出来。
10、访问者模式，原本由各个实体对象提供的数据，改由visitor来获取，这样不会侵入对应的实体对象。

实践经验

设计模式这么多，什么时候使用呢？如果碰到一个场景就想着使用设计模式，肯定是不对的，只有在特定场景下才能发挥作用。

1、全局配置类与单例，通常程序为了支持灵活配置，会需要一份动态配置文件来实现多种行为，这种情况下，全局配置类应该是个单例，能在全局访问到，并且不需要随着函数的参数传递到最深处。
2、对象池的实现通常会和工厂方法一起使用，利用 ObjectFactory::Create() 来统一创建对象，而不是在代码的任意一处 new 对象。