13.3.12代理模式
代理模式为其他对象提供一个代理以控制对这个对象的访问。
当无法或不想直接访问某个对象或访问某个对象粗耨困难时可以通过一个代理对象来间接访问，为了保证客户端使用的透明性，委托对象与代理对象需要实现相同的接口。
iOS在不同界面间的传值、Android的Binder和Notification机制都使用了代理模式。
组合模式将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。
此模式的使用场景：
(1)表示对象的部分-整体层次结构时。
(2)从一个整体中能够独立出部分模块或功能时。
如文件系统，View和ViewGroup系统就使用了组合模式。
适配器模式将一个类的接口转换成客户希望的另外一个接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。也可以像Listview那样，利用此模式隔离变化，使得UI架构变得更灵活。
此模式的使用场景：
(1)系统需要使用现有的类，而类的接口不符合系统的需要，即接口不兼容。。
(2)想要建议一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。
(3)需要一个统一的输出接口，而输入端的类型不可预知。
如在APP中为了实现某个功能，需要集成三方库或SDK，而这些三方库或SDK可能会采用不同的厂商的，为了替换方便，需要使用适配器模式。对于同一份数据，用户可能选择不同的显示方式，如不同风格的菜单，也可采用适配器模式。
外观模式要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行，定义了一个高层接口，使得这一子系统更加容易使用。
此模式的使用场景：
(1)为一个复杂子系统提供一个简单接口，对外隐藏子系统的具体实现、隔离变化。
(2)在构建一个层次结构的子系统时，使用外观模式定义子系统中每层的入口点，简化各层之间的依赖关系。
如封装API给调用者使用的时候，可以使用外观模式。
桥接模式将抽象部分与它的实现部分分离，使它们都可以独立地变化。
此模式的使用场景：
(1)当一个对象有多个变化因素的时候，通过抽象这些变化因素，将依赖具体实现，修改为依赖抽象。
(2)当某个变化因素在多个对象中共享时，我们可以抽象出这个变化因素，然后实现这些不同的变化因素。
(3)当我们期望一个对象的多个变化因素可以动态的变化，而且不影响客户的程序的使用时。
(4)如果系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次间建立静态的继承关系，可以使用此模式使它们在抽象层建立一个关联关系。
如电商APP在计算商品总价时，依赖商品数量和促销政策这两个因素。同一中促销政策，对于不同的商品数量，促销折扣也不一样，这样计算商品总价时，就会有N种情况，此时就可使用桥接模式。
参考：《Android源码设计模式解析与实战》
