桥接模式是怎么诞生的呢？来看一个场景。
一个软件企业开发一套系统，要兼容所有的不同类型硬件和和各种操作系统。不同种类硬件主要是 电脑、平板电脑、手机。各种操作系统是苹果系统、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();
// 平板电脑兼容配置 .....
}
}
/**************************结果*****************************/
电脑类兼容：鸿蒙 操作系统 手机兼容：鸿蒙 操作系统
分析桥接模式
通过上面的例子，我们看出来，桥接模式通过把业务场景中不同的两个维度独立了出来，在试用的时候根据需要类配合试用，调用的时候更加灵活。而且需要扩展时，只需要扩展有变化的维度即可。
如果不用桥接模式，那么就需要 电脑、平板电脑、手机都扩展鸿蒙操作系统的类，如果是实际运用中场景更复杂，扩展的工作量就更大。
另外也体现了开闭原则。因为扩展时候顶层的抽样类和接口是不变化的，两个维护的关联也是不变的，只需要根据扩展添加新类即可。
通过这个设计模式的代码实现方式，我们也总结一下：继承的耦合性更强，而组合或者说是聚合的灵活性更高。
那么这个模式的本质是什么呢：就是分析业务场景变化维度。然后让不同的维度相互独立，一个维度变化另外一个维度不用跟着修改，使得代码更容易扩展。
原文地址：https://www.cnblogs.com/pengweiqiang/p/11072384.html