桥接模式

桥 接模式属于对象结构型模式，其意图是将抽象的部分和它的实现部分分离，使他们都可以独立的变化。当一个抽象可能有多个实现时，通常用继承来协调他们。抽象 类的定义对该抽象的接口。而具体的子类则用不同的方式加以实现，但是此方法有时不够灵活。继承机制将抽象部分与他的视线部分固定在一起，使得难以对抽象部 分和实现部分独立地进行修改、扩充和充用。

实用性：

1.          你不希望在抽象和他的实现部分之间有一个固定的邦定关系，如在程序的运行时刻实现部分应该可以被选择或者切换。

2.          类的抽象以及他的视像都可以通过生成子类的方法加以扩充。这时 bridge 模式使你可以对不同的抽象接口和实现部分进行组合，并对他们进行扩充。

3.          对一个抽象的实现部分的修改应该对客户不产生影响，即客户的代码不需要重新编译。

4.          你想对客户完全隐藏抽象的实现部分。

5.          你想在多个实现间 共享实现，但同时要求客户并不知道这一点。

参与者 :

       Abstraction: 定义抽象类的接口，维护一个指向实现者 (implementor) 接口类型 (imageImp) 的指针

       RefinedAbstraction(BMPImg) ：扩充由 Abstraction 定义的接口。

       Implementor(ImageImp): 定义实现类的接口，该接口不一定要与 Abstraction 的接口完全一致，事实上这两个接口可以完全不同。一般来讲 Implementor 接口仅提供基本操作，而 Abstraction 则定义了这些基本操作的较高层次的操作。

       ConcreteImplementor(UnixImp) ：实现 ImageImp 并定义它的具体实现。

图1

Bridge 模式的优点：

1.         分离接口和实现部分。一个实现不必不变得邦定在一个接口上。抽象类的实现可以在运行的时刻进行配置，一个对象甚至可以在运行的时候改变它的实现。

2.         提高可扩充性 你可以独立地对 Abstraction 和 Implementor 层次结构进行扩充。

3.         实现细节对客户的透明 你可以对可以隐藏实现细节。

生活中的一个例子:
    就拿汽车在路上行驶的来说。即有小汽车又有公共汽车，它们都不但能在市区中的公路上行驶，也能在高速公路上行驶。这你会发现，对于交通工具（汽车）有不同 的类型，然而它们所行驶的环境（路）也在变化，在软件系统中就要适应两个方面的变化？怎样实现才能应对这种变化呢？
概述:
在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。
意图:
　　　将抽象部分与实现部分分离，使它们都可以独立的变化。
                                                                    ——《设计模式》GOF
结构图:
                                
传统的做法:
        通过类继承的方式来做上面的例子;
先看一下类结构图:
     
代码实现:

 1 namespace  CarRunOnRoad
 2 {
 3      // 路的基类;
 4      public    class  Road
 5      {
 6          public   virtual   void  Run()
 7          {
 8             Console.WriteLine( " 在路上 " );
 9         }
10     }
11      // 高速公路;
12      public   class  SpeedWay : Road
13      {
14          public   override   void  Run()
15          {
16             Console.WriteLine( " 高速公路 " );
17         }
18     }
19      // 市区街道;
20      public   class  Street : Road
21      {
22          public   override   void  Run()
23          {
24             Console.WriteLine( " 市区街道 " );
25         }
26     }
27      // 小汽车在高速公路上行驶;
28      public   class  CarOnSpeedWay : SpeedWay
29      {
30          public   override   void  Run()
31          {
32             Console.WriteLine( " 小汽车在高速公路上行驶 " );
33         }
34     }
35      // 公共汽车在高速公路上行驶;
36      public   class  BusOnSpeedWay : SpeedWay
37      {
38          public   override   void  Run()
39          {
40             Console.WriteLine( " 公共汽车在高速公路上行驶 " );
41         }
42     }
43      // 小汽车在市区街道上行驶;
44      public   class  CarOnStreet : Street
45      {
46          public   override   void  Run()
47          {
48             Console.WriteLine( " 汽车在街道上行驶 " );
49         }
50     }
51      // 公共汽车在市区街道上行驶;
52      public   class  BusOnStreet : Street
53      {
54          public   override   void  Run()
55          {
56             Console.WriteLine( " 公共汽车在街道上行驶 " );
57         }
58     }
59    
60 }

客户端调用:

 1 static   void  Main( string [] args)
 2          {
 3              // 小汽车在高速公路上行驶
 4             CarOnSpeedWay Car  =   new  CarOnSpeedWay();
 5             Car.Run();
 6
 7             Console.WriteLine( " =========================== " );
 8
 9              // 公共汽车在街道上行驶
10             BusOnStreet Bus  =   new  BusOnStreet();
11             Bus.Run();
12
13             Console.Read();
14         }

缺点:
     但是我们说这样的设计是脆弱的，仔细分析就可以发现，它还是存在很多问题，首先它在遵循开放-封闭原则的同时，违背了类的单一职责原则，即一个类只有一个 引起它变化的原因，而这里引起变化的原因却有两个，即路类型的变化和汽车类型的变化；其次是重复代码会很多，不同的汽车在不同的路上行驶也会有一部分的代 码是相同的； 再次是类的结构过于复杂，继承关系太多，难于维护，最后最致命的一点是扩展性太差。如果变化沿着汽车的类型和不同的道路两个方向变化，我们会看到这个类的结构会迅速的变庞大。


应用设计模式
       桥接模式（Bridge）来做;
先看一下类结构图:
                     
                          
代码实现:

 1 namespace  CarRunOnRoad_Bridge_
 2 {
 3
 4      // 抽象路
 5      public   abstract   class  AbstractRoad
 6      {
 7          protected  AbstractCar car;
 8          public  AbstractCar Car
 9          {
10              set
11              {
12                 car  =  value;
13             }
14         }
15
16          public   abstract   void  Run();
17     }
18
19      // 高速公路
20      public   class  SpeedWay : AbstractRoad
21      {
22          public   override   void  Run()
23          {
24             car.Run();
25             Console.WriteLine( " 高速公路上行驶 " );
26         }
27     }
28
29      // 市区街道
30      public   class  Street : AbstractRoad
31      {
32          public   override   void  Run()
33          {
34             car.Run();
35             Console.WriteLine( " 市区街道上行驶 " );
36         }
37     }
38 }

 1 namespace  CarRunOnRoad_Bridge_
 2 {
 3      // 抽象汽车 
 4      public   abstract   class  AbstractCar
 5      {
 6          public   abstract   void  Run();
 7     }
 8
 9      // 小汽车;
10      public   class  Car : AbstractCar
11      {
12          public   override   void  Run()
13          {
14             Console.Write( " 小汽车在 " );
15         }
16     }
17
18      // 公共汽车
19      public   class  Bus : AbstractCar
20      {
21          public   override   void  Run()
22          {
23             Console.Write( " 公共汽车在 " );
24         }
25     }
26 }

客户端调用:

 1   static   void  Main( string [] args)
 2          {
 3              // 小汽车在高速公路上行驶;
 4             AbstractRoad Road1  =   new  SpeedWay();
 5             Road1.Car  =   new  Car();
 6             Road1.Run();
 7             Console.WriteLine( " ========================= " );
 8
 9              // 公共汽车在高速公路上行驶;
10             AbstractRoad Road2  =   new  SpeedWay();
11             Road2.Car  =   new  Bus();
12             Road2.Run();
13
14            
15
16             Console.Read();
17         }

      可以看到，通过对象组合的方式，Bridge 模式把两个角色之间的继承关系改为了耦合的关系，从而使这两者可以从容自若的各自独立的变化，这也是Bridge模式的本意。
      这样增加了客户程序与路与汽车的耦合。其实这样的担心是没有必要的，因为这种耦合性是由于对象的创建所带来的，完全可以用创建型模式去解决。在应用时结合创建型设计模式来处理具体的问题。
应用设计模式:
       桥接模式（Bridge）来做(多维度变化 );
       结合上面的例子,增加一个维度"人",不同的人开着不同的汽车在不同的路上行驶(三个维度);
       结合上面增加一个类"人",并重新调用.
代码实现:

 1 namespace  CarRunOnRoad_Bridge_
 2 {
 3      abstract   class  people
 4      {
 5         AbstractRoad road;
 6          public  AbstractRoad Road
 7          {
 8              get
 9              {
10                  return  road;
11             }
12              set
13              {
14                 road  =  value;
15             }
16         }
17          public   abstract   void  Run();
18
19     }
20      class  Man : people
21      {
22          public   override   void  Run()
23          {
24             Console.Write( " 男人开着 " );
25             Road.Run();
26         }
27     }
28
29      class  WoMan : people
30      {
31          public   override   void  Run()
32          {
33             Console.Write( " 女人开着 " );
34             Road.Run();
35         }
36     }
37 }

客户端调用:

  1   static   void  Main( string [] args)
 2          {
 3             
 4              // 男人开着公共汽车在高速公路上行驶;
 5             Console.WriteLine( " ========================= " );
 6
 7             AbstractRoad Road3  =   new  SpeedWay();
 8             Road3.Car  =   new  Bus();
 9
10             people p  =   new  Man();
11             p.Road  =  Road3;
12             p.Run();
13
14             Console.Read();
15         }

效果及实现要点：
1．Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
2．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同路上的不同汽车。
3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。

适用性：
   在以下的情况下应当使用桥梁模式：
1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。
总结：
      Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。

桥接模式与装饰的区别:
装饰模式:
      这两个模式在一定程度上都是为了减少子类的数目，避免出现复杂的继承关系。但是它们解决的方法却各有不同，装饰模式把子类中比基类中多出来的 部分放到单独的类里面，以适应新功能增加的需要，当我们把描述新功能的类封装到基类的对象里面时，就得到了所需要的子类对象，这些描述新功能的类通过组合 可以实现很多的功能组合 .
桥接模式：
          桥接模式则把原来的基类的实现化细节抽象出来，在构造到一个实现化的结构中，然后再把原来的基类改造成一个抽象化的等级结构，这样就可以实现系统在多个维度上的独立变化 。