桥梁模式

概述：

        将抽象性化与实现化脱耦，使二者可以独立的变化。

        耦合就是两个实体行为的某种强关联，将强关联去掉，或将强关联变为弱关联就是脱耦。

       强关联就是在编译时期已经确定，无法在运行时期动态改变的关联。弱关联就是可以动态确定并且可以在运行时期动态改变的关联，继承关系是强关联，聚合关系是弱关联。

       将两个角色之间的继承关系变为聚合关系，就是将强关联变为弱关联，在一个软件系统的抽象化和实现化之间使用组合而不是继承关系，从而可以使两者独立的变化。

抽象类(Abstraction):定义抽象类的接口,维护一个指向Implementor类型对象的指针

扩充抽象类(RefinedAbstraction)：扩充由Abstraction定义的接口

实现类接口(Implementor)：定义实现类的接口，该接口不一定要与 Abstraction的接口完全一致；事实上这两个接口可以完全不同。一般来讲， Implementor接口仅提供基本操作，而 Abstraction则定义了基于这些基本操作的较高层次的操作。

具体实现类(ConcreteImplementor)：实现Implementor接口并定义它的具体实现。

 

一个普通的开关控制的电灯、电风扇等等，都是桥接的例子。开关的目的是将设备打开或关闭。实际的开关可以是简单的双刀拉链开关，也可以是调光开关。

飞机类型和制造商分离

 

abstract class Airplan{
    public AirplanMarker airplanMarker;
    abstract void fly();
}

class PassangePlan extends Airplan {

    @Override
    void fly() {
        // TODO Auto-generated method stub
        
    }
}

class CaogoPlan extends Airplan {

    @Override
    void fly() {
        // TODO Auto-generated method stub
        
    }
}
abstract class AirplanMarker {
    abstract void produce();
}

class Airbus extends AirplanMarker{

    @Override
    void produce() {
        // TODO Auto-generated method stub
        
    }
    
}

 

桥梁模式的优点：

●　抽象和实现分离

这是桥梁模式的主要特点，它完全是为了解决继承的缺点而提出的设计模式。在该模式下，实现可以不受抽象的约束，不用再绑定在一个固定的抽象层次上。

●　优秀的扩展能力

 

●　实现细节对客户透明

客户不用关心细节的实现，它已经由抽象层通过聚合关系完成了封装。

 

桥梁模式的使用场景：

●　不希望或不适用使用继承的场景

例如继承层次过渡、无法更细化设计颗粒等场景，需要考虑使用桥梁模式。

●　接口或抽象类不稳定的场景

明知道接口不稳定还想通过实现或继承来实现业务需求，那是得不偿失的，也是比较失败的做法。

●　重用性要求较高的场景

设计的颗粒度越细，则被重用的可能性就越大，而采用继承则受父类的限制，不可能出现太细的颗粒度。

 

桥梁模式的注意事项：

使用桥梁模式时主要考虑如何拆分抽象和实现，并不是一涉及继承就要考虑使用该模式，那还要继承干什么。

桥梁模式的意图还是对变化的封装，尽量把可能变化的因素封装到最细、最小的逻辑单元中，避免风险扩散。

系统设计时，发现类的继承有N层时，可以考虑使用桥梁模式。