设计模式--BRIDGE

结构型模式2:

桥梁模式："将抽象化与实现化脱耦"，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。

BRIDGE―早上碰到MM，要说早上好，晚上碰到MM，要说晚上好；碰到MM穿了件新衣服，要说你的衣服好漂亮哦，碰到MM新做的发型，要说你的头发好漂亮哦。不要问我“早上碰到MM新做了个发型怎么说”这种问题，自己用BRIDGE组合一下不就行了.

BRIDGE模式图:

下图所示就是一个实现了桥梁模式的示意性系统的结构图：

代码实现：

public abstract class Abstraction{

 protected Implementor impl;  

  public Abstraction(Implementor impl){  

        this.impl = impl;  

    }  

  public void operation(){  

   

        impl.operationImpl();  

    }  

}

public class RefinedAbstraction extends Abstraction{

public RefinedAbstraction(Implementor impl) {  

        super(impl);  

}

 public void otherOperation(){  

}  

}

public abstract class Implementor {  

 public abstract void operationImpl();  

}

}

public class ConcreteImplementorA extends Implementor {

@Override

    public void operationImpl() {  

        //具体操作  

    }  

}

public class ConcreteImplementorB extends Implementor {  

      

    @Override

    public void operationImpl() {  

        //具体操作  

    }  

      

}

适用环境：

1)当你的系统中有多个地方要使用到类似的行为，或者是多个类似行为的组合时，可以考虑使用桥梁模式来提高重用，并减少因为行为的差异而产生的子类。

2)系统中某个类的行为可能会有几种不同的变化趋势，为了有效的将变化封装，可以考虑将类的行为抽取出来。

3)当然上面的情况也可以是这样，行为可能要被不同相似类使用，也可以考虑使用桥梁模式来实现。

优点：
桥梁模式使用了低耦合性的组合代替继承，使得它具备了不少好处
1)将可能变化的部分单独封装起来，使得变化产生的影响最小，不用编译不必要的第代码。
2)抽象部分和实现部分可以单独的变动，并且每一部分的扩充都不会破坏桥梁模式搭起来架子。
3)对于客户程序来说，你的实现细节是透明的。