设计模式之桥接模式

设计模式之桥接模式

特点

　　将抽象部分与实现部分分离，使他们都可以独立地进行变化。为了达到让抽象部分和实现部分独立变化的目的，抽象部分会拥有实现部分的接口对象，有了实现部分的接口对象之后，就能够通过这个接口来调用具体实现部分的功能。桥接在程序上就体现成了抽象部分拥有实现部分的接口对象，维护桥接就是维护这个关系，也就是说，桥接模式中的桥接是一个单方向的关系，只能够抽象部分去使用实现部分的对象，而不能反过来。
　　桥接模式适用于以下的情形：

如果一个系统需要在构建的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系，可以通过桥接模式使他们在抽象层建立一个关联关系；
那些不希望使用继承或因为多层次继承导致系统类的个数极具增加的系统；
一个类存在两个独立变化的维度，而这两个维度都需要进行扩展。

桥接模式也分为四个角色：

Abstraction：抽象部分
该类保持一个对实现部分对象的引用，抽象部分中的方法需要调用实现部分的对象来实现，该类一般为抽象类；
RefinedAbstraction：优化的抽象部分
抽象部分的具体实现，该类一般对抽象部分的方法进行完善和扩展；
Implementor：实现部分
可以为接口或者是抽象类，其方法不一定要与抽象部分中的一致，一般情况下是由实现部分提供基本的操作，而抽象部分定义的则是基于实现部分基本操作的业务方法；
ConcreteImplementorA 和 ConcreteImplementorB ：实现部分的具体实现
完善实现部分中定义的具体逻辑。

一个具体的例子：

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();  
}  

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

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