设计模式——结构型

结构模式研究类和对象之间的组织结构与关系。基于类的结构模式通过在对象的类之间建立静态的继承关系而得到一个结构（基于类的适配器模式），一般只存在继承关系；基于对象的结构模式关心类与对象的组合，通过关联关系在一个类中定义另一个类的实例对象，然后通过该对象调用其方法（绝大多数的结构模式），多用关联关系替代继承关系。

代理模式（Proxy)为其他对象提供一种代理以控制对该对象的访问
装饰模式（Decorator）动态地给一个对象添加一些额外的职责，就 增加功能来说，装饰模式比生成子类更为灵活
适配器模式（Adapter）将一个类的接口变换成客户端所期待的另一 接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一 起工作
组合模式（Composite）也叫合成模式，将对象组合成树形结构以 表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的 使用具有一致性
桥梁模式（Bridge）也叫桥接模式，将抽象和实现解耦，使得两者 可以独立的变化
外观模式（Facade）也叫门面模式，要求一个子系统的外部与其内 部的通信必须通过一个统一的对象进行，外观模式提供一个高层次的 接口，使得子系统更易于使用
享元模式（Flyweight）是池技术的重要实现方式，使用共享对象可 有效地支持大量的细粒度的对象

适配器模式(adapter)

主要用于接口不匹配的情形，使得原本接口不兼容的类可以一起工作。调用已有的类的方法，避免修改原有的类（oc原则）。可以在两个不相关的软件组件间进行信息交换（解耦合），增加了透明性和复用性，灵活性好，易扩展。额外的中间步骤，时间延迟。
类适配器通过继承得到要适应的类的接口（方法），只能匹配它的基类
对象适配器通过聚合调用要适应的类的方法。也可以与需要被匹配的类的派生类匹配，但不能使用在派生类中扩展的方法
对象适配器只需要实现接口的行为而不需要作为派生类继承基类操作的“负担”

桥梁模式（bridge)

聚合代替继承。抽象定义仅仅依赖于实施者的接口，而不依赖于具体实现部分。实现抽象定义和实现的分离，使两部分互不依赖，单独开发，使得一个抽象定义可以与多种不同的实现一起工作。

装饰模式（Decorator）

通过聚合以对客户透明的方式（接口不变）动态地给一个对象附加上更多的责任。比静态继承更灵活

装饰类是component的派生类，同时聚合了一个component的对象（或任意component子类的对象），装饰类中不能存在没有经过修改的继承方法。
装饰类继承了component的方法，也可以在覆写继承来的方法的同时加入新的方法。客户通过component的接口间接使用装饰类，处理结果被通过装饰类所聚合的对象转交给客户程序，附加的功能会在调用委托的方法之前或之后执行。

外观模式（Facade）

迪米特法则：应当使得软件的不同对象彼此之间尽量“老死不相往来”，降低系统维护成本

外观模式是一个简单的，统一的接口，通过这个接口可以使用子系统中的类，隐藏了子系统内部的具体实现，把对自身的调用转移到子系统的类，综合了子系统的功能。简化子系统功能的使用，拆分子系统和调用它的客户类。常用于数据源系统的面向对象外壳。

组合模式（composite）

处理树形结构的系统，模糊了简单元素和复杂元素的概念，用相同的处理方法应对不同复杂度（层次）的元素。发送给组合的消息一方面由当前节点的方法处理，另一方面会被委托给它的下一层执行。使得客户程序与复杂元素的内部结构解耦。

代理模式（proxy）

把一个实际存在的对象隐藏在一个与它具有相同接口的代理者身后。代理者封装实际对象的接口，把对方法的调用委托给实际的对象，并且可以插入新的功能。

享元模式（flyweight）

运用共享技术有效地支持大量细粒度的对象，避免大量拥有相同内容的小类的开销，使大家共享一个对象