定义：桥接模式（Bridge），将抽象部分与它的实现部分分离，使它们都能可以独立地变化。
动机：在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。
结构图：
可以看出，这个系统含有两个等级结构，也就是：
由抽象化角色和修正抽象化角色组成的抽象化等级结构。
由实现化角色和两个具体实现化角色所组成的实现化等级结构。
桥接模式所涉及的角色有：
抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。
修正抽象化(RefinedAbstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。
实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。
具体实现化(ConcreteImplementor)角色：这个角色给出实现化角色接口的具体实现。
代码示例：http://www.cnblogs.com/houleixx/archive/2008/02/23/1078877.html（经典示例）
抽象化角色：手机品牌
package com.jin.model.bridge;
public abstract class HandsetBrand {
protected HandsetSoft soft;
public void setSoft(HandsetSoft soft) {
this.soft = soft;
}
public abstract void run();
}
修正抽象化角色：具体手机品牌N
package com.jin.model.bridge;
public class HandsetBrandN extends HandsetBrand {
@Override
public void run() {
soft.run();
}
}
修正抽象化角色：具体手机品牌M
package com.jin.model.bridge;
public class HandsetBrandM extends HandsetBrand {
@Override
public void run() {
soft.run();
}
}
实现化角色：手机软件
package com.jin.model.bridge;
public abstract class HandsetSoft {
public abstract void run();
}
具体实现化角色：手机通讯录
package com.jin.model.bridge;
public class HandsetAdressList extends HandsetSoft {
@Override
public void run() {
System.out.println("运行手机通讯录！");
}
}
具体实现化角色：手机游戏
package com.jin.model.bridge;
public class HandsetGame extends HandsetSoft {
@Override
public void run() {
System.out.println("运行手机游戏！");
}
}
客户端：
package com.jin.model.bridge;
public class Client {
/**
* @param args
*/
public static void main(String[] args) {
HandsetBrand hb;
hb = new HandsetBrandM();
hb.setSoft(new HandsetGame());
hb.run();
hb.setSoft(new HandsetAdressList());
hb.run();
hb = new HandsetBrandN();
hb.setSoft(new HandsetGame());
hb.run();
hb.setSoft(new HandsetAdressList());
hb.run();
}
}
效果及实现要点：
1．Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
2．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同路上的不同汽车。
3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。
适用性：
1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。
总结：
Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这个面向对象原则。