桥接模式

说明<基于拷贝加上自己的理解修改而成，真正原文难以定位，原作者如果看到可以提个醒，我在此附上原链接>

实例分析：

    路有高速和低速等，车有大车和小车等。如果业务只针对路和车展开，那么现在有两个维度，每一个维度可能有多种类型，比如路有N种类型，车有M中类型，那么车跑在路上就有N*M中组合。假设现在再加一个维度“人”，人有大人，老人，男人 ，女人等B种类型，那么现在的维度组合数是N*M*B。很明显，这个组合数已经相当大，如果面对的是一个比较大的项目，那么规模可能超出我们的承受范围。下来切入正题

概述:
软件设计本身就是对生活情景的抽象，上述实例分析就是软件设计中面对的一个问题，如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度并且控制编码的规模呢？这就要使用Bridge模式。
桥接模式目的:
　　　将抽象部分与实现部分分离，使它们都可以独立的变化。
                         

上面这些话我也没看懂。。太抽象了，但是一看代码你就明白是怎么回事了。
结构图:

传统的做法:
        通过类继承的方式来做上面的例子;
先看一下类结构图:

代码实现：

[java]  view plain  copy

 print ?

1.         //基类 路  
2. class Road {  
3.     void run() {  
4.         System.out.println("路");  
5.     }  
6. }  
7.   
8. //市区街道  
9. class Street extends Road {  
10.     void run() {  
11.         System.out.println("市区街道");  
12.     }  
13. }  
14.   
15. //高速公路  
16. class SpeedWay extends Road {  
17.     void run() {  
18.         System.out.println("高速公路");  
19.     }  
20. }  
21. //小汽车在市区街道行驶  
22. class CarOnStreet extends Street {  
23.     void run() {  
24.         System.out.println("小汽车在市区街道行驶");  
25.     }  
26. }  
27. //小汽车在高速公路行驶  
28. class CarOnSpeedWay extends SpeedWay {  
29.     void run() {  
30.         System.out.println("小汽车在高速公路行驶");  
31.     }  
32. }  
33. //公交车在市区街道行驶  
34. class BusOnStreet extends Street {  
35.     void run() {  
36.         System.out.println("公交车在市区街道行驶");  
37.     }  
38. }  
39. //公交车在高速公路行驶  
40. class BusOnSpeedWay extends SpeedWay {  
41.     void run() {  
42.         System.out.println("公交车在高速公路行驶");  
43.     }  
44. }  
45. //测试  
46. public static void main(String[] args) {  
47.       
48.     //小汽车在高速公路行驶  
49.     CarOnSpeedWay carOnSpeedWay = new CarOnSpeedWay();  
50.     carOnSpeedWay.run();  
51.     //公交车在市区街道行驶  
52.     BusOnStreet busOnStreet = new BusOnStreet();  
53.     busOnStreet.run();  
54.   
55. }  

缺点:
     但是我们说这样的设计是脆弱的，仔细分析就可以发现，它还是存在很多问题，首先它在遵循开放-封闭原则的同时，违背了类的单一职责原则，即一个类只有一个引起它变化的原因，而这里引起变化的原因却有两个，即路类型的变化和汽车类型的变化；其次是重复代码会很多，不同的汽车在不同的路上行驶也会有一部分的代码是相同的；

再次是类的结构过于复杂，继承关系太多，难于维护，最后最致命的一点是扩展性太差。如果变化沿着汽车的类型和不同的道路两个方向变化，我们会看到这个类的结构会迅速的变庞大。

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

代码实现：

[java]  view plain  copy

 print ?

1. abstract class AbstractRoad{  
2. /*
3.  * 这里是把车的维度耦合到了路上，假如现在有人的维度，那么还可以把人分离到一个单独的维度进行定义
4.  * 然后耦合到这里来；在实际的业务中可能会把不同的维度进行灵活的组合，不只是将其他维度耦合到一个
5.  * 维度中。
6.  */
7.     AbstractCar aCar;  
8.     void run(){};  
9. }  
10. abstract class AbstractCar{  
11.     void run(){};  
12. }  
13.   
14. class Street extends AbstractRoad{  
15.     @Override  
16.     void run() {  
17.         // TODO Auto-generated method stub  
18.         super.run();  
19.         aCar.run();  
20.         System.out.println("在市区街道行驶");  
21.     }  
22. }  
23. class SpeedWay extends AbstractRoad{  
24.     @Override  
25.     void run() {  
26.         // TODO Auto-generated method stub  
27.         super.run();  
28.         aCar.run();  
29.         System.out.println("在高速公路行驶");  
30.     }  
31. }  
32. class Car extends AbstractCar{  
33.     @Override  
34.     void run() {  
35.         // TODO Auto-generated method stub  
36.         super.run();  
37.         System.out.print("小汽车");  
38.     }  
39. }  
40. class Bus extends AbstractCar{  
41.     @Override  
42.     void run() {  
43.         // TODO Auto-generated method stub  
44.         super.run();  
45.         System.out.print("公交车");  
46.     }  
47. }  
48.   
49. public static void main(String[] args){  
50.       
51.     AbstractRoad speedWay = new SpeedWay();  
52.     speedWay.aCar = new Car();  
53.     speedWay.run();  
54.       
55.     AbstractRoad street = new Street();  
56.     street.aCar = new Bus();  
57.     street.run();  
58. }  

前两者的实现方式可以看到，传统的实现方式是通过继承的方式来实现的，这样做的缺点就是层层继承，类之间的耦合性太大，而且是两个维度上交织在一起，动其中的一个类就会导致其他类的修改，这在程序设计中是非常要命的，因为程序设计本身的特性就是迭代加修改，但不能因为几句代码的问题去修改整个业务逻辑，越到开发后期修改的成本越大；而桥接模式则是将不同的维度进行了分割，每一个维度单独进行定义，然后在业务逻辑中进行耦合，这样的好处就是当需要修改某一个维度的时候不需要去修改全部的业务逻辑，只需要针对当前维度进行一些修改，大大简化了修改的难度，同时降低了程序维护的成本。
应用设计模式:
     桥接模式（Bridge）来做(多维度变化);
       结合上面的例子,增加一个维度"人",不同的人开着不同的汽车在不同的路上行驶(三个维度);
       结合上面增加一个类"人",并重新调用.
代码实现:

[java]  view plain  copy

 print ?

1. abstract class People {  
2. /*
3.  * 注意与上边的进行比较，上方的耦合方式是把车耦合到了路上，这是把路耦合到了人当中，可以级联耦合
4.  * 不管怎么样，贵在灵活运用
5.  */
6.     AbstractRoad road;  
7.     void run() {}  
8. }  
9.   
10. class Man extends People{  
11.     @Override  
12.     void run() {  
13.         // TODO Auto-generated method stub  
14.         super.run();  
15.         System.out.print("男人开着");  
16.         road.run();  
17.     }  
18. }  
19. class Woman extends People{  
20.     @Override  
21.     void run() {  
22.         // TODO Auto-generated method stub  
23.         super.run();  
24.         System.out.print("女人开着");  
25.         road.run();  
26.     }  
27. }  
28.   
29. public static void main(String[] args) {  
30.   
31.     AbstractRoad speedWay = new SpeedWay();  
32.     speedWay.aCar = new Car();  
33.       
34.     People man = new Man();  
35.     man.road = speedWay;  
36.     man.run();  
37. }  

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

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