Bridge Pattern，是结构型设计模式之一，
定义：
将抽象部分与实现部分分离，使得他们可以独立的进行变化
使用场景：
从定义中可以看到，这里的“桥梁”链接了“抽象”和“实现部分”，但是事实上，任何多维度变化类或者说多个树状类之间的耦合都可以使用桥接模式来实现解耦。
如果一个系统需要在构建的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系，可以通过桥接模式使他们在抽象层建立一个关联关系。
对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，也可以考虑使用桥接模式。
一个雷存在两个独立变化的维度，且这两个维度都需要进行扩展
实现：
咖啡有大小杯、加糖不加糖。
有一个咖啡抽象类Coffee，两个子类实现它LargeeCoffee和SmallCoffee，构造函数里面传入CoffeeAdditives抽象类的具体实现类。
CoffeeAdditives抽象类有两个具体实现类，Ordinary（原味）和Sugar（加糖）。
当我们调用Coffee实现类LargeeCoffee或者SmallCoffee的makeCoffee方法时，根据大小杯来实现不同的代码，同时方法里面又根据传入的是Ordinary或者Sugar对象来实现了加糖/不加糖的逻辑。
当我们多了一个中杯的咖啡时候，就新增一个MiddleCoffee类，同时客户端增加相应的代码就行了。
如果我们要加蜂蜜，咖啡伴侣，盐等，我们就去创建CoffeeAdditives的具体不同的实现类，不管是Coffee类还是CoffeeAdditives变化了对于对方而言都是独立的，之间没有过多的交集。
Android中的桥接模式
比较典型的是Window与WindowManager之间的关系，在framework中，Window和PhoneWindow构成窗口的抽象部分，Window为抽象接口，PhoneWindow为具体实现和扩展，而WindowManager为实现部分的基类。WindowManagerImpl为实现部分具体的逻辑实现。其使用WindowManagerGlobal通过IWindowManager接口与WindowManagerService（WMS）进行交互，并由WMS完成具体的窗口管理工作。
Window类里面有个setWindowManager方法，设置了WindowManager进来，实现了WindowManager和Window的绑定。
又比如在View视图层级中，CheckBox、CompoundButton、Button、TextView和View之间构成了继承关系的层级视图，每一个层级视图仅仅是对一种类型控件的描述。
真正绘制到屏幕的部分是由于View相关的功能实现类DisplayList、HardwareLayer和Canvas负责。
除此之外Adapter和AdapterView之间也可以看作是对桥接模式的应用。
如果留意的话，会发现在开发中其实有很多的地方都用到了桥接模式。
总结：
在实际开发中，桥接模式有很多地方都可以运用，但是使用得却不多，因为设计起来比较复杂，对抽象与现实的分离不好把握，是不是需要分离，如何分离？都对开发者有一定的经验要求。
桥接模式好处是显而易见的，分离抽象与实现、灵活的扩展以及对客户来说透明的实现等。
