桥接模式就是将高维类的降维处理，将一件事物本征的东西抽象成不同的类，通过不同的类的组合描述一件事物.其实这与一般的架构设计中要求的模块功能单一化的原则是一致的。同时也符合合成聚合原则。组合优于继承.
生活中的一个例子:
就拿汽车在路上行驶的来说。即有小汽车又有公共汽车,货车,拖拉机等等，它们都不但能在市区中的公路上行驶，也能在高速公路上行驶。这你会发现，对于交通工具（汽车）有不同的类型，然而它们所行驶的环境（路）也在变化，在软件系统中就要适应两个方面的变化？怎样实现才能应对这种变化呢？
概述:
在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。
意图:
将抽象部分与实现部分分离，使它们都可以独立的变化。 ——《设计模式》GOF
传统的做法:
通过类继承的方式来做上面的例子;
先看一下类结构图:
缺点:
但是我们说这样的设计是脆弱的，
- 首先它在遵循开放-封闭原则的同时，违背了类的单一职责原则，即一个类只有一个引起它变化的原因，而这里引起变化的原因却有两个，即路类型的变化和汽车类型的变化；
- 其次是重复代码会很多，不同的汽车在不同的路上行驶也会有一部分的代码是相同的；
- 类的结构过于复杂，继承关系太多，难于维护，
- 最后最致命的一点是扩展性太差。如果变化沿着汽车的类型和不同的道路两个方向变化，我们会看到这个子类的结构会迅速的变庞大。
应用设计模式
使用桥接模式（Bridge）来做, 先看一下类结构图:
namespace CarRunOnRoad_Bridge_ {
//抽象路
public abstract class AbstractRoad
{
protected AbstractCar car;
public AbstractCar Car
{
set
{
car = value;
}
}
public abstract void Run();
}
//高速公路
public class SpeedWay : AbstractRoad
{
public override void Run()
{
car.Run();
Console.WriteLine("高速公路上行驶");
}
}
//市区街道
public class Street : AbstractRoad
{
public override void Run()
{
car.Run();
Console.WriteLine("市区街道上行驶");
}
}
}
namespace CarRunOnRoad_Bridge_
{
//抽象汽车
public abstract class AbstractCar
{
public abstract void Run();
}
//小汽车;
public class Car : AbstractCar
{
public override void Run()
{
Console.Write("小汽车在");
}
}
//公共汽车
public class Bus : AbstractCar
{
public override void Run()
{
Console.Write("公共汽车在");
}
}
}
客户端调用:
static void Main(string[] args) {
//小汽车在高速公路上行驶;
AbstractRoad Road1 = new SpeedWay();
Road1.Car = new Car();
Road1.Run();
Console.WriteLine("=========================");
//公共汽车在高速公路上行驶;
AbstractRoad Road2 = new SpeedWay();
Road2.Car = new Bus();
Road2.Run();
Console.Read();
}可以看到，通过对象组合的方式，Bridge 模式把两个角色之间的继承关系改为了耦合的关系，从而使这两者可以从容自若的各自独立的变化，这也是Bridge模式的本意。
这样增加了客户程序与路与汽车的耦合。其实这样的担心是没有必要的，因为这种耦合性是由于对象的创建所带来的，完全可以用创建型模式去解决。在应用时结合创建型设计模式来处理具体的问题。
应用桥接模式（Bridge）来做多维度变化; 结合上面的例子,如果在增加一个维度"人",新司机,老司机, 男司机, 女司机 等等,不同的人开着不同的汽车在不同的路上行驶(三个维度); 对于这样的新增需求, 做到同时遵守开闭原则和单一职责.
效果及实现要点：
1．Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
2．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同路上的不同汽车。
3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。
适用性：
在以下的情况下应当使用桥接模式：
1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。
Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。
参与者Abstraction
1. 定义抽象接口。
2. 拥有一个Implementor类型对象引用。
RefinedAbstraction
1. 扩展Abstraction中的接口定义。
Implementor
1. Implementor是具体实现的接口，Implementor和Abstraction接口并不一定完全一致(注：Proxy和ISubject接口一一对应)，实际上这两个接口可以完全不一样，Implementor提供具体操作方法，而Abstraction提供更高层次的调用。
ConcreteImplementor
1. 实现Implementor接口，给出具体实现。
public abstract class Implementor {
public abstract void operation();
}
public class ConcreteImplementorA extends Implementor {
@Override
public void operation() {
System.out.println("ConcreteImplementorA");
}
}
public class ConcreteImplementorB extends Implementor {
@Override
public void operation() {
System.out.println("ConcreteImplementorB");
}
}
public abstract class Abstraction {
protected Implementor implementor;
public Abstraction(Implementor implementor) {
this.implementor = implementor;
}
public void operationAAA() {
implementor.operation();
}
}
public class RefinedAbstraction extends Abstraction {
public RefinedAbstraction(Implementor implementor) {
super(implementor);
}
public void operationSSS() {
}
} 桥接模式与装饰的区别:
装饰模式:
这两个模式在一定程度上都是为了减少子类的数目，避免出现复杂的继承关系。但是它们解决的方法却各有不同，装饰模式把子类中比基类中多出来的部分放到单独的类里面，以适应新功能增加的需要，当我们把描述新功能的类封装到基类的对象里面时，就得到了所需要的子类对象，这些描述新功能的类通过组合可以实现很多的功能组合 .
桥接模式：
桥接模式则把原来的基类的实现化细节抽象出来，在构造到一个实现化的结构中，然后再把原来的基类改造成一个抽象化的等级结构，这样就可以实现系统在多个维度上的独立变化 。
设计模式-----桥接模式(Bridge Pattern)
设计模式之桥接模式
