之前用7篇Blog篇幅的时间对结构型模式进行了学习，这里对结构型模式进行一个小结。之前的7篇Blog都贴到这里：
结构型模式文章列表
结构型模式主要总结了一些类或对象组合在一起的经典结构，这些经典的结构可以解决特定应用场景的问题。结构型模式包括：代理模式、桥接模式、装饰器模式、适配器模式、门面模式、组合模式、享元模式
- 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
- 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
- 装饰（Decorator）模式：动态地给对象增加一些职责，即增加其额外的功能。
- 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度。
- 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
- 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
- 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
接下来再回顾下这些结构型模式的核心概念。
结构型模式使用频次
依据是否常用来划分，我觉得适配器模式、代理模式、装饰模式、桥接模式比较常用。外观模式（接口聚合、感觉严格意义不太算作模式）、享元模式（需要大量相似对象时才会用到）以及组合模式（需要特点数据结构才会用到）很少用到
结构型模式重点回顾
下面重点回顾下结构型模式的核心概念
1 适配器模式
代理模式、装饰器模式提供的都是跟原始类相同的接口，而适配器提供跟原始类不同的接口。适配器模式是用来做适配的，它将不兼容的接口转换为可兼容的接口，让原本由于接口不兼容而不能一起工作的类可以一起工作。
适配器模式有两种实现方式：类适配器和对象适配器。其中，类适配器使用继承关系来实现
对象适配器使用组合关系来实现。
适配器模式是一种事后的补救策略，用来补救设计上的缺陷。如果在设计初期，我们就能规避接口不兼容的问题，那这种模式就无用武之地了。在实际的开发中，有两种场景比较适合使用适配器模式：封装有缺陷的接口设计 ; 统一多个类的接口设计
2 代理模式
代理模式在不改变原始类接口的条件下，为原始类定义一个代理类，主要目的是控制访问，而非加强功能，这是它跟装饰器模式最大的不同。
一般情况下，我们让代理类和原始类实现同样的接口。但是，如果原始类并没有定义接口，并且原始类代码并不是我们开发维护的。在这种情况下，我们可以通过让代理类继承原始类的方法来实现代理模式。
静态代理需要针对每个类都创建一个代理类，并且每个代理类中的代码都有点像模板式的重复代码，增加了维护成本和开发成本。对于静态代理存在的问题，我们可以通过动态代理来解决。我们不事先为每个原始类编写代理类，而是在运行的时候动态地创建原始类对应的代理类，然后在系统中用代理类替换掉原始类。
代理模式常用在业务系统中开发一些非功能性需求：监控、统计、鉴权、限流、事务、幂等、日志。我们将这些附加功能与业务功能解耦，放到代理类统一处理，让程序员只需要关注业务方面的开发。除此之外，代理模式还可以用在 RPC、缓存等应用场景中
3 装饰器模式
装饰器模式主要解决继承关系过于复杂的问题，通过组合来替代继承，给原始类添加增强功能。这也是判断是否该用装饰器模式的一个重要的依据。
除此之外，装饰器模式还有一个特点，那就是可以对原始类嵌套使用多个装饰器。为了满足这样的需求，在设计的时候，装饰器类需要跟原始类继承相同的抽象类或者接口，并且方法实现要使用方法入参对象实现。
4 桥接模式
桥接模式有两种理解方式。第一种理解方式是将抽象和实现解耦，让它们能独立开发。这种理解方式比较特别，应用场景也不多。另一种理解方式更加简单，等同于组合优于继承设计原则，这种理解方式更加通用，应用场景比较多。
不管是哪种理解方式，它们的代码结构都是相同的，都是一种类之间的组合关系。对于第一种理解方式，弄懂定义中“抽象”和“实现”两个概念，是理解它的关键。定义中的抽象，指的并非抽象类或接口，而是被抽象出来的一套类库，它只包含骨架代码，真正的业务逻辑需要委派给定义中的实现来完成。而定义中的实现，也并非接口的实现类，而是的一套独立的类库。抽象和实现独立开发，通过对象之间的组合关系组装在一起。
5 外观模式
外观模式原理、实现都非常简单，应用场景比较明确。它通过封装细粒度的接口，提供组合各个细粒度接口的高层次接口，来提高接口的易用性，或者解决性能、分布式事务等问题。
6 组合模式
组合模式并非组合关系（通过组合来组装两个类）。这里讲的组合模式，主要是用来处理树形结构数据。正因为其应用场景的特殊性，数据必须能表示成树形结构，这也导致了这种模式在实际的项目开发中并不那么常用。但是，一旦数据满足树形结构，应用这种模式就能发挥很大的作用，能让代码变得非常简洁。它又分为安全式组合模式：
和透明式组合模式
组合模式的设计思路，与其说是一种设计模式，倒不如说是对业务场景的一种数据结构和算法的抽象。其中，数据可以表示成树这种数据结构，业务需求可以通过在树上的递归遍历算法来实现。组合模式，将一组对象组织成树形结构，将单个对象和组合对象都看作树中的节点，以统一处理逻辑，并且它利用树形结构的特点，递归地处理每个子树，依次简化代码实现。
7 享元模式
所谓享元，就是被共享的单元。享元模式的意图是复用对象，节省内存，前提是享元对象是不可变对象。具体来讲，当一个系统中存在大量重复对象的时候，我们就可以利用享元模式，将对象设计成享元，在内存中只保留一份实例，供多处代码引用，这样可以减少内存中对象的数量，以起到节省内存的目的。
实际上，不仅仅相同对象可以设计成享元，对于相似对象，我们也可以将这些对象中相同的部分（字段），提取出来设计成享元，让这些大量相似对象引用这些享元。
总结一下
结构型模式主要总结了一些类或对象组合在一起的经典结构，这些经典的结构可以解决特定应用场景的问题。所以我们在使用结构型模式时的出发点还是场景，例如想要进行接口兼容我们可以考虑适配器模式、想要统一加日志、AOP等可以考虑代理模式，想要功能随意组合增强的文件系统可以使用装饰器模式、想要独立变化的JDBC接口标准和开发厂商实现可以使用桥接模式，想要处理组织关系开发人事系统可以使用组合模式，想要统一接口调用可以使用外观模式，想要节省内存、共享对象可以使用享元模式。从场景出发！
