23种设计模式09---桥接（Bridge）模式

生活中的一个例子:

拿汽车在路上行驶的来说。既有小汽车又有公共汽车，它们都不但能在市区中的公路上行驶，也能在高速公路上行驶。这你会发现，对于交通工具（汽车）有不同的类型，它们所行驶的环境（路）也有不同类型，在软件系统中就要适应两个方面（不同车型，不同道路）的变化，怎样实现才能应对这种变化呢？

概述:

在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。

桥接模式的意图

　　　将抽象部分与实现部分分离，使它们都可以独立的变化。
             ——《设计模式》GOF

实现上面的例子

1、使用传统方式，通过类的继承

代码实现

    //基类 路    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();    }

使用继承的缺点:
  该设计存在很多问题，首先它在违背开闭原则（OCP）的同时，违背了单一职责问题，即一个类只有一个引起它变化的因素，而在这里引起变化的因素由两个：路类型变化和车类型变化，
  其次是重复代码过多，不同汽车在不同的路上行驶，有部分代码相同。
  再次，是类的结构太复杂，继承关系太多，难于维护，
  最致命的一点是扩展性很差，如果变化沿着车型和路型两个维度变化，我们可以看到类的结构迅速变大。

2、使用桥接模式(Bridge)

类图

抽象车型

public abstract class AbstractCar{    void run(){};}

抽象路型， 在这个地方最重要一点是抽象路于车型以组合的方式，Bridge 模式把两个角色之间的继承关系改为了耦合的关系，从而使这两者可以从容自若的各自独立的变化，这也是Bridge模式的本意。

public abstract class AbstractRoad{    //持有抽象车型的一个引用    AbstractCar aCar;    void run(){};}

   这样增加了客户程序与路与汽车的耦合。其实这样的担心是没有必要的，因为这种耦合性是由于对象的创建所带来的，完全可以用创建型模式去解决。在应用时结合创建型设计模式来处理具体的问题。

子类实现

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

应用设计模式:拓展一个维度

桥接模式（Bridge）来做(多维度变化);
结合上面的例子,增加一个维度”人”,不同的人开着不同的汽车在不同的路上行驶(三个维度);
   结合上面增加一个类”人”,并重新调用.
代码实现:

public abstract class People {    AbstractRoad abstractRoad;    void run(){}}public class Man extends People{    @Override    public void run() {        super.run();        System.out.print("男人开着");        abstractRoad.run();    }}public class Woman extends People{    @Override    public void run() {        super.run();        System.out.print("女人开着");        abstractRoad.run();    }}public static void main(String[] args){    AbstractRoad speedWay = new SpeedWay();    speedWay.aCar = new Car();    People man = new Man();    man.abstractRoad = speedWay;    man.run();    AbstractRoad street = new Street();    street.aCar = new Bus();    People woman = new Woman();    woman.abstractRoad = street;    woman.run();}

效果及实现要点：

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

适用性：

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

总结：

  Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。