设计模式之（九）桥接模式（Bridge）

　　桥接模式是怎么诞生的呢？来看一个场景。

　　一个软件企业开发一套系统，要兼容全部的不一样类型硬件和和各类操做系统。不一样种类硬件主要是 电脑、平板电脑、手机。各类操做系统是苹果系统、windows 系统、Linux 系统。设计人员给出了须要适配的类图。

                                              

         这个设计根据列出来了须要建立的 7 个类。经过集成的方式来实现。这样就实现了软件如要适配的软硬件的须要。可是有什么问题呢。很显然就是扩展起来笔记麻烦。例如：华为的鸿蒙操做系统出来了，并且是手机、平板、电脑都能用的操做系统。这样咱们就须要扩展 3 个类。这仍是简单的业务状况。要是复杂再复杂些的。那么这样的扩展就比较麻烦。那么接下来咱们接触的 桥接模式就可以很好的解决这个问题。先看下桥接模式的定义：

        将抽象部分与实现部分分离，使它们均可以独立的变化。

        这种定义我老是弄不清除抽象部分和实现部分，都值得是什么。可是后面的 均可以独立的变化 看明白了。经过看其余的一些文档。实际就是在业务场景中有两个及以上的维度变化时，把不一样的维度都独立成类，某个维度的类变化影响不到另一个维度的变化便可。而后在须要使用的试用使他们经过聚合的方式联系起来一块儿工做。这种聚合犹如桥梁，所以这种解决问题设计方式就叫桥接模式。

        经过桥接模式的分析上面的业务场景。  首先来分析变化维度，很明显操做系统是一个维度；各种硬件是一个维度。根据交接模式改造一下上面的结构：

         接下来用简单的单位实现一下这个设计示意图。

// 硬件抽象类 
public abstract class AbstractHardware {
    
    private SoftwareOS os;
    
    public AbstractHardware(SoftwareOS os){
        this.os = os;
    }
    
    public SoftwareOS getOs() {
        return os;
    }
    
    public abstract void runOS();
}

//电脑，继承硬件抽象类
public class Computer extends AbstractHardware {

    public Computer(SoftwareOS os) {
        super(os);
        // TODO Auto-generated constructor stub
    }
    
    public void runOS(){
        String Str = this.getOs().funRun();
        System.out.println("电脑类兼容："+Str);
    }
    
}

//手机类，继承硬件抽象类
public class Cellphone extends AbstractHardware{

    public Cellphone(SoftwareOS os) {
        super(os);
        // TODO Auto-generated constructor stub
    }

    @Override
    public void runOS() {
        // TODO Auto-generated method stub
        String str = this.getOs().funRun();
        System.out.println("手机兼容："+str);
    }
    
}

//平板电脑类，继承硬件抽象类
public class boardCom extends AbstractHardware {
       ......
}

//操做系统接口
public interface SoftwareOS {
    
    public String funRun();
}

//苹果操做系统，实现操做系统接口
public class Mac implements SoftwareOS {

    @Override
    public String funRun() {
        // TODO Auto-generated method stub
        return "Mac 操做系统";
    }
}

//安卓操做系统，继承操做系统接口
public class Andriod implements SoftwareOS {

    @Override
    public String funRun() {
        // TODO Auto-generated method stub
        return " Andriod 操做系统";
    }

}

// Linux 类，实现操做系统接口
public class Linux implements SoftwareOS {

    @Override
    public String funRun() {
        // TODO Auto-generated method stub
        return "Linux 操做系统";
    }
    
}

// Windows 类，实现操做系统接口
public class Windows implements SoftwareOS {

    @Override
    public String funRun() {
        // TODO Auto-generated method stub
        return "Windows 操做系统";
    }
}

// 测试类
public class Client {
    public static void main(String[] args) {
        
        // 电脑类兼容配置
        AbstractHardware computer = new Computer(new Mac());
        computer.runOS();
        
        computer = new Computer(new Linux());
        computer.runOS();
        
        //手机类兼容配置
        AbstractHardware cphone = new Cellphone(new Andriod());
        cphone.runOS();
        
        cphone = new Cellphone(new Mac());
        cphone.runOS();
        
        // 平板电脑兼容配置 .....
        
    }
}

/**************************结果*****************************/

　　　　电脑类兼容：Mac 操做系统
　　　　电脑类兼容：Linux 操做系统
　　　　
　　　　手机兼容： Andriod 操做系统
　　　　手机兼容：Mac 操做系统
　　　　

　　随着科技产业的不断发展，华为开发出来全方位操做系统：鸿蒙，这时候就须要扩展操做系统这个维度的类。扩展以下：

//鸿蒙操做系统，实现操做系统接口
public class HongMeng implements SoftwareOS {

    @Override
    public String funRun() {
        // TODO Auto-generated method stub
        return "鸿蒙 操做系统";
    }

}

// 测试类
public class Client {
    public static void main(String[] args) {
        
        // 电脑类兼容配置
        AbstractHardware computer = new Computer(new HongMeng());
        computer.runOS();
        //手机类兼容配置
        AbstractHardwarecphone = new Cellphone(new HongMeng());
        cphone.runOS();
        
        // 平板电脑兼容配置 .....
    }
}

/**************************结果*****************************/

　　　　电脑类兼容：鸿蒙 操做系统
　　　　手机兼容：鸿蒙 操做系统

 

 分析桥接模式

　　经过上面的例子，咱们看出来，桥接模式经过把业务场景中不一样的两个维度独立了出来，在试用的时候根据须要类配合试用，调用的时候更加灵活。并且须要扩展时，只须要扩展有变化的维度便可。

　　若是不用桥接模式，那么就须要 电脑、平板电脑、手机都扩展鸿蒙操做系统的类，若是是实际运用中场景更复杂，扩展的工做量就更大。

　　另外也体现了开闭原则。由于扩展时候顶层的抽样类和接口是不变化的，两个维护的关联也是不变的，只须要根据扩展添加新类便可。

       经过这个设计模式的代码实现方式，咱们也总结一下：继承的耦合性更强，而组合或者说是聚合的灵活性更高。

　　那么这个模式的本质是什么呢：就是分析业务场景变化维度。而后让不一样的维度相互独立，一个维度变化另一个维度不用跟着修改，使得代码更容易扩展。