结构型设计模式
结构型设计模式主要总结了一些类或对象组合在一起的经典结构，这些经典的结构可以解决特定应用场景的问题。结构模式包括：代理模式、桥接模式、装饰器模式、适配器模式、门面模式、组合模式、亨元模式。
1. 代理模式
实现方式：代理模式在不改变原始类接口的条件下，为原始类定义一个代理类，主要目的是为了控制访问，而非加强功能，这是它跟装饰器模式最大的不同。一般情况下，我们让代理类和原始类实现同样的接口。但是，如果原始类并没有定义接口，并且原始类代码并不是我们开发维护的。在这种情况下，我们可以通过让代理类继承原始类的方法来实现代理模式。
静态代理与动态代理：静态代理需要针对每个类都创建一个代理类，并且每个代理类中的代码都有点像模板式的重复代码，增加了维护成本和开发成本。对于静态代理存在的问题，可以通过动态代理来解决。不事先为每个原始类编写代理类，而是在运行的时候动态地创建原始类对应的代理类，然后在系统中用代理类替换掉原始类。
使用场景：代码模式常用在业务系统中开发一些非功能性的需求，比如：监控、统计、鉴权、限流、事务、幂等、日志。将这些附加功能与业务功能解耦，放到代理类统一处理，只需要关注业务方面的开发。除此之外，代理模式还可以用在RPC、缓存等应用场景中。
2. 桥接模式
桥接模式的代码实现比较简单，但是理解起来比较有难度，并且应用场景也比较局限，所以，相对来说，桥接模式在实际项目中并没有那么常用，只需要简单了解，见到能认识就可以，并不是学习的重点。
理解方式：将抽象与实现解耦，让它们能够独立开发。这种理解方式比较特别，应用场景也不多。另外一种理解方式更加简单，等同于组合优于继承的设计原则，这种理解方式更加通用，应用场景比较多。不管是哪种理解方式，它们的代码结构都是相同的，都是一种类之间的组合关系。对于第一种理解方式，弄懂定义中 “抽象” 和 “实现” 两个概念，是理解它的关键。定义中的 “抽象”，指的并非是抽象类或接口，而是被抽象出来的一套类库，它只包含骨架代码，真正的业务逻辑需要委派给定义中的 “实现” 来完成。而定义中的 “实现” ，也并非 “接口的实现类”，而是一套独立的类库，“抽象” 和 “实现” 独立开发，通过对象的组合关系组装在一起。
3. 装饰器模式
装饰器模式主要解决继承关系过于复杂的问题，通过组合替代继承，给原始类添加增强功能。这也是判断是否该用装饰器模式的一个重要依据。除此之外，装饰器模式还有一个特点，就是可以对原始类嵌套使用多个装饰器。为了满足这样的需求，在设计的时候，装饰类需要跟原始类继承相同的抽象类或者接口。
4. 适配器模式
定义：代理模式、装饰器模式提供的都是跟原始类相同的接口，而适配器提供跟原始类不同的接口。适配器模式是用来做适配的，它将不兼容的接口转换为可兼容的接口。让原本由于接口不兼容而不能一起工作的类可以一起工作。
实现方式：类适配器和对象适配器。其中，类适配器使用继承关系来实现，对象适配器使用组合关系来实现。
适配器模式是一种事后的补救策略，用来补救设计上的缺陷。应用这种模式算是 “无奈之举”。如果在设计初期，就能规避接口不兼容的问题，那么这种模式就无用武之地了。在实际开发中，什么情况下才会出现接口不兼容呢？有下面 5 种场景：
- 封装有缺陷的接口设计
- 统一多个类的接口设计
- 替换依赖的外部系统
- 兼容老版本接口
- 适配不同格式的数据
5. 门面模式
门面模式原理、实现都比较简单，应用场景比较明确。通过封装细粒度的接口，提供组合各个细粒度接口的高层次接口，来提高接口的易用性，或解决性能、分布式事务问题。
6. 组合模式
组合模式跟面向对象设计中的组合关系 ( 通过组合来组装两个类 )，完全是两码事。这里讲的 “组合模式”，主要是用来处理树形结构数据。正是因为其应用场景的特殊性，数据必须能表示成树形结构，这也导致了这种模式在实际的项目开发中并不那么常用。但是，一旦数据满足树形结构，应用这种模式就能发挥很大的作用，能让代码变得非常简洁。
组合模式，更像是对业务场景的一个数据结构和算法的抽象。其中，数据可以表示成树这种数据结构，业务需求可以通过在树上的递归遍历算法来实现。组合模式，将一组对象组织成树形结构，将单个对象和组合对象都看作树中的节点，以统一处理逻辑，并且利用树形结构的特点，递归地处理每个子树，依次简化代码实现。
7. 亨元模式
亨元就是被共享的单元。亨元模式的意图是复用对象，节省内存，当然前提是亨元对象是不可变对象。
具体来说，当一个系统中存在大量重复对象的时候，就可以利用亨元模式，将对象设计成亨元，在内存实例中保存一份实例，供多处代码引用，这样可以减少内存中对象的数量，以达到节省内存的目的。实际上，不仅仅相同的对象可以设计成亨元，对于相似对象，也可以将这些对象中相同的部分 (字段) ，提取出来设计成亨元，让大量相似对象引用这些亨元。
