结构模式--之--桥梁模式

桥梁模式的用意是“将抽象化与实现化脱耦，使得二者可以独立地变化”

 

所谓脱耦，就是两个实体的行为的某种强关联。而将它们的强关联去掉，就是耦合的解脱或称为脱耦。或者说，将它们之间的强关联改换成弱关联。

所强关联，就是在编译时期已经确定的，无法在运行期间动态改变的关联。所谓弱关联，就是可以动态地确定并且可以在运行时期动态地改变的关联。在java语言中，类继承关系是强关联，而聚合有关系是弱关联。

桥梁模式中的所谓脱耦，就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以相对独立地变化。这就是桥梁模式的用意。

 

桥梁模式的系统含有两个等级结构：

1.由抽象化角色和修正抽象化角色组成的抽象化等级结构

2.由实现化角色和两个具体实现化角色所组成的实现化等级结构。

桥梁模式所涉及的角色：

1.抽象化（Abstraction）角色：抽象化给出的定义，并保存一个对实现化对象的引用

2.修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义

3.实现化（Implementor）角色:这个角色给出实现化角色的接口，但不给出具体的实现，这个接口不一定和抽象化角色的接口相同，实际上，这两个接口可以非常 不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。

4.具体实现化（Concrete Implementor）角色：这个角色给出实现化角色接口的具体实现。

一般而言，实现化角色中的每一个方法都应当有一个抽象化角色中某一个方法与之相对应。但是反过来则不一定。换言之，抽象化角色的接口比实现化角色的接口宽。抽象化角色除了提供与实现化角色相关的方法外，还可能提供其它的商业方法，而实现化角色则往往仅为实现抽象化角色的相关行为而存在。

 

救命代码：

public class BridgeTest {
    public static void main(String[] args) {
        Abstraction imp = new RefinedAbstraction(new ConcreteImplementorA());
        imp.operation();
    }

}
//抽象化角色
abstract class Abstraction{
    //实现化角色
    protected Implementor imp;
    
    //通过向实现化角色委派完成
    public void operation(){
        imp.operationImp();
    }
}
//修正抽象化角色
class RefinedAbstraction extends Abstraction{
    public RefinedAbstraction(Implementor imp){
        this.imp = imp;
    }
    
    //修正化角色可以置换掉实现化角色的方法
    public void operation(){
        System.out.println("Do anotherThing....");
    }
}
//实现化角色
abstract class Implementor{
    public abstract void operationImp();
}

//具体实现化角色
class ConcreteImplementorA extends Implementor{

    @Override
    public void operationImp() {
        System.out.println("Do something....");
    }
    
}

桥梁模式是“对变化的封装”原则以及组合、聚合复用原则的极好的例子。在飞机制造系统中，飞机的种类和制造商代表两个不同的变化因素，而这两个变化因素需要独立地变化。按照对变化的封装原则，它们应当被封装到继承的等级结构中，而这两个等级结构之间应当选择使用聚合关系，避免出现静态的强耦合，这就导致了桥梁模式的设计方案。

 

什么情况下使用桥梁模式？

1.如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系

2.设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的

3.一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合

4.虽然在系统中使用继承是没有问题，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。