《Java设计模式》之桥接模式

Bridge模式的概念

Bridge 模式是构造型的设计模式之一。Bridge模式基于类的最小设计原则，通过使用封装，聚合以及继承等行为来让不同的类承担不同的责任。它的主要特点是把抽象（abstraction）与行为实现（implementation）分离开来，从而可以保持各部分的独立性以及应对它们的功能扩展。

Bridge模式的应用场景

面向对象的程序设计（OOP）里有类继承（子类继承父类）的概念，如果一个类或接口有多个具体实现子类，如果这些子类具有以下特性：
- 存在相对并列的子类属性。
- 存在概念上的交叉。
- 可变性。
我们就可以用Bridge模式来对其进行抽象与具体，对相关类进行重构。

桥接模式的适用：

你不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如：程序的实现部分在运行时需要被选择或者切换。

类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这时Bridge模式使你可以对不同的抽象接口和实现部分进行组合，并分别对它们进行扩充。

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

有许多类要生成。这种情况下你必须将一个对象分解成两个部分。这种类层次结构为“嵌套的普化”。

你想在多个对象间共享实现（可能使用引用计数），但同时要求客户并不知道这一点。

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

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

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

代码实现：

         //基类 路
 class Road {
     void run() {
         System.out.println("路");
     }
 }

 //市区街道
 class Street extends Road {
     void run() {
         System.out.println("市区街道");
     }
 }

 //高速公路
 class SpeedWay extends Road {
     void run() {
         System.out.println("高速公路");
     }
 }
 //小汽车在市区街道行驶
 class CarOnStreet extends Street {
     void run() {
         System.out.println("小汽车在市区街道行驶");
     }
 }
 //小汽车在高速公路行驶
 class CarOnSpeedWay extends SpeedWay {
     void run() {
         System.out.println("小汽车在高速公路行驶");
     }
 }
 //公交车在市区街道行驶
 class BusOnStreet extends Street {
     void run() {
         System.out.println("公交车在市区街道行驶");
     }
 }
 //公交车在高速公路行驶
 class BusOnSpeedWay extends SpeedWay {
     void run() {
         System.out.println("公交车在高速公路行驶");
     }
 }
 //测试
 public static void main(String[] args) {

     //小汽车在高速公路行驶
     CarOnSpeedWay carOnSpeedWay = new CarOnSpeedWay();
     carOnSpeedWay.run();
     //公交车在市区街道行驶
     BusOnStreet busOnStreet = new BusOnStreet();
     busOnStreet.run();

 }

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

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

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

代码实现：

 abstract class AbstractRoad{
     AbstractCar aCar;
     void run(){};
 }
 abstract class AbstractCar{
     void run(){};
 }

 class Street extends AbstractRoad{
     @Override
     void run() {
         // TODO Auto-generated method stub
         super.run();
         aCar.run();
         System.out.println("在市区街道行驶");
     }
 }
 class SpeedWay extends AbstractRoad{
     @Override
     void run() {
         // TODO Auto-generated method stub
         super.run();
         aCar.run();
         System.out.println("在高速公路行驶");
     }
 }
 class Car extends AbstractCar{
     @Override
     void run() {
         // TODO Auto-generated method stub
         super.run();
         System.out.print("小汽车");
     }
 }
 class Bus extends AbstractCar{
     @Override
     void run() {
         // TODO Auto-generated method stub
         super.run();
         System.out.print("公交车");
     }
 }

 public static void main(String[] args){

     AbstractRoad speedWay = new SpeedWay();
     speedWay.aCar = new Car();
     speedWay.run();

     AbstractRoad street = new Street();
     street.aCar = new Bus();
     street.run();
 }

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

 abstract class People {
     AbstractRoad road;

     void run() {}
 }

 class Man extends People{
     @Override
     void run() {
         // TODO Auto-generated method stub
         super.run();
         System.out.print("男人开着");
         road.run();
     }
 }
 class Woman extends People{
     @Override
     void run() {
         // TODO Auto-generated method stub
         super.run();
         System.out.print("女人开着");
         road.run();
     }
 }

 public static void main(String[] args) {

     AbstractRoad speedWay = new SpeedWay();
     speedWay.aCar = new Car();

     People man = new Man();
     man.road = speedWay;
     man.run();
 }

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

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

 

本文借鉴文章：

http://blog.csdn.net/jason0539/article/details/22568865