设计模式之（九）桥接模式（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();
        
        // 平板电脑兼容配置 .....
    }
}

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

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

 分析桥接模式

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

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

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

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

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