Structural

思想：让类和类进行组合，获得更大的结构。

模式名称	模式名称	作用
结构型模式	适配器模式 ★★★★☆	将一个类的接口转换成客户希望的另外一个接口。使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
	桥接模式 ★★★☆☆	将抽象部分与实际部分分离，使它们都可以独立的变化。
	组合模式 ★★☆☆☆	将对象组合成树形结构以表示“部分--整体”的层次结构。使得用户对单个对象和组合对象的使用具有一致性。
	装饰模式 ★★★☆☆	动态的给一个对象添加一些额外的职责。就增加功能来说，此模式比生成子类更为灵活。
	外观模式 ★★★★★	为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
	享元模式 ★☆☆☆☆	以共享的方式高效的支持大量的细粒度的对象。
	代理模式 ★★★★☆	为其他对象提供一种代理以控制对这个对象的访问。

Proxy

代理：指具有与被代理的对象具有相同的接口的类，客户端必须通过代理与被代理的目标类交互。

代理通常为在被代理对象基础上提供额外功能附加/增强。

• subject 抽象主题：真实主题与代理主题的共同接口。
• RealSubject 真实主题：定义了代理角色所代表的真实对象。
• **Proxy 代理主题：**含有对真实主题角色的引用，代理角色通常在将客户端调用传递给真是主题对象之前或者之后执行某些操作，而不是单纯返回真实的对象。

注：代理和被代理都实现了相同的主题接口。

Go 中被代理类（的抽象）以组合的方式（作为字段）在代理类中。

:smile:

1. 能够协调调用者和被调用者，在一定程度上降低了系统的耦合度。
2. 客户端可以针对抽象主题角色进行编程，增加和更换代理类无须修改源代码，符合开闭原则，系统具有较好的灵活性和可扩展性。

:cry:

1. 代理实现较为复杂。

:construction_worker:

1. 为其他对象提供一种代理以控制对这个对象的访问。

Decorator

装饰：动态地给一个对象增加一些额外的职责，就增加对象功能来说，装饰模式比生成子类实现更为灵活。

• Component（抽象构件）：它是具体构件和抽象装饰类的共同父类，声明了在具体构件中实现的业务方法，它的引入可以使客户端以一致的方式处理未被装饰的对象以及装饰之后的对象，实现客户端的透明操作。
• ConcreteComponent（具体构件）：它是抽象构件类的子类，用于定义具体的构件对象，实现了在抽象构件中声明的方法，装饰器可以给它增加额外的职责（方法）。

通过 Wrapper 将原有类变成一个新的类。Go 中不允许接口有成员，所以抽象装饰器只能是 struct，以组合的方式。

:smile:

1. 对于扩展一个对象的功能，装饰模式比继承更加灵活性，不会导致类的个数急剧增加。
2. 可以通过一种动态的方式来扩展一个对象的功能，从而实现不同的行为。
3. 可以对一个对象进行多次装饰。
4. 具体构件类与具体装饰类可以独立变化，用户可以根据需要增加新的具体构件类和具体装饰类，原有类库代码无须改变，符合“开闭原则”。

:cry:

1. 使用装饰模式进行系统设计时将产生很多小对象，大量小对象的产生势必会占用更多的系统资源，影响程序的性能。
2. 复杂度 ↑，对于多次装饰的对象，调试时寻找错误可能需要逐级排查，较为繁琐。

:construction_worker:

1. 动态、透明的方式给单个对象添加职责。
2. 当不能采用继承的方式对系统进行扩展或者采用继承不利于系统扩展和维护时可以使用装饰模式。

vs

装饰器模式关注于在一个对象上动态的添加方法。→ 将原始对象作为一个参数传给装饰者的构造器。

代理模式关注于控制对对象的访问，对客户端隐藏了被代理对象。→ 在一个代理类中创建一个对象的实例。

Adaptor

适配器：将一个类的接口转换成客户希望的另外一个接口。将两个不相关的类关联起来。

• **Target 目标抽象类：**目标抽象类定义客户所需接口，可以是一个抽象类或接口，也可以是具体类。
• **Adapter 适配器类 ：**适配器可以调用另一个接口，作为一个转换器，对 Adaptee 和 Target 进行适配，适配器类是适配器模式的核心，在对象适配器中，它通过继承 Target 并关联一个 Adaptee 对象使二者产生联系。
• **Adaptee 适配者类 ：**适配者即被适配的角色，它定义了一个已经存在的接口，这个接口需要适配，适配者类一般是一个具体类，包含了客户希望使用的业务方法，在某些情况下可能没有适配者类的源代码。

**客户使用的接口实际上是经适配器转换后的接口，客户无需感知。**适配器持有被被适配器的实例。

:smile:

1. 将目标类和适配者类解耦，通过引入一个适配器类来重用现有的适配者类，无须修改原有结构。
2. 增加了类的透明性和复用性，将具体的业务实现过程封装在适配者类中，对于客户端类而言是透明的，而且提高了适配者的复用性，同一个适配者类可以在多个不同的系统中复用。
3. 灵活性和扩展性都非常好，可以很方便地更换适配器，也可以在不修改原有代码的基础上增加新的适配器类，完全符合“开闭原则”。

:cry:

1. 适配器中置换适配者类的某些方法比较麻烦。

:construction_worker:

1. 系统需要使用一些现有的类，而这些类的接口（如方法名）不符合系统的需要，甚至没有这些类的源代码。
2. 想创建一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。

Facade