设计模式：桥接模式（Bridge）

本文主要是介绍设计模式：桥接模式（Bridge），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

欢迎支持笔者新作：《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》，同时欢迎关注笔者的微信公众号：朱小厮的博客。

欢迎跳转到本文的原文链接：https://honeypps.com/design_pattern/bridge/

定义：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
意图：将抽象与实现解耦。
桥接模式主要应对的是由于实际的需要，某个类具有两个或者两个以上的维度变化（违反了SRP原则），如果只是用继承将无法实现这种需要，或者使得设计变得相当臃肿。

这里写图片描述

桥接模式所涉及的角色

Abstraction：定义抽象接口，拥有一个Implementor类型的对象引用
RefinedAbstraction：扩展Abstraction中的接口定义
Implementor：是具体实现的接口，Implementor和RefinedAbstraction接口并不一定完全一致，实际上这两个接口可以完全不一样Implementor提供具体操作方法，而Abstraction提供更高层次的调用
ConcreteImplementor：实现Implementor接口，给出具体实现

举个简单例子（评判一个地方红烧肉的口味，这里出现了两个维度的变化：地域和餐馆品牌）
1 Implementor(这里是餐馆的接口)

public interface Restaurant
{public String taste();
}

2 ConcreteImplementor（具体的餐馆：小南国和外婆家）

public class XiaoNanGuo implements Restaurant
{@Overridepublic String taste(){return "红烧肉比较好吃";}
}
public class WaiPojia implements Restaurant
{@Overridepublic String taste(){return "红烧肉比较一般";}
}

3 Abstraction（城市抽象类，这里包含了一个Implementor）

public abstract class AbstractCityArea
{protected Restaurant restaurant;public AbstractCityArea(Restaurant restaurant){this.restaurant = restaurant;}public abstract void commentTaste();
}

4 RefinedAbstraction（具体的城市类）

public class NanjingRestaurant extends AbstractCityArea
{public NanjingRestaurant(Restaurant restaurant){super(restaurant);}@Overridepublic void commentTaste(){System.out.println("南京的"+super.restaurant.taste());}
}
public class ShanghaiRestaurant extends AbstractCityArea
{public ShanghaiRestaurant(Restaurant restaurant){super(restaurant);}@Overridepublic void commentTaste(){System.out.println("上海的"+super.restaurant.taste());}
}

5 测试代码
（加入有个外国人来到中国，比如去了上海要吃红烧肉，正好他去了小南国，这时候他要评价了）

        Restaurant rest = new XiaoNanGuo();AbstractCityArea sr = new ShanghaiRestaurant(rest);sr.commentTaste();

输出：上海的红烧肉比较好吃
（有一天他又来到南京，去外婆家去吃红烧肉，吃完又要评价了）

        Restaurant rest = new WaiPojia();AbstractCityArea sr = new NanjingRestaurant(rest);sr.commentTaste();

输出：南京的红烧肉比较一般~

也许这个例子不够形象，那再举个例子好了：交通工具在路上行驶，这里有两个维度的变化，首先交通工具的类型不同，其次路也分水泥路和柏油路。
1 交通工具（Implementor）

public interface Vehicle
{public void drive();
}

2 具体的交通工具（ConcreteImplementor）

public class Car implements Vehicle
{@Overridepublic void drive(){System.out.print("小轿车");}
}
public class Bus implements Vehicle
{@Overridepublic void drive(){System.out.print("大巴");}
}

3 抽象的路（Abstraction）

public abstract class Road
{protected Vehicle vehicle;public Road(Vehicle vehicle){this.vehicle = vehicle;}public abstract void driveOnRoad();
}

4 具体的路

public class UnpavedRoad extends Road
{public UnpavedRoad(Vehicle vehicle){super(vehicle);}@Overridepublic void driveOnRoad(){super.vehicle.drive();System.out.println("行驶在石子路");}
}
public class CementRoad extends Road
{public CementRoad(Vehicle vehicle){super(vehicle);}@Overridepublic void driveOnRoad(){super.vehicle.drive();System.out.println("行驶在水泥路");}
}

5 测试代码：

        Road road = new CementRoad(new Car());road.driveOnRoad();

输出：小轿车行驶在水泥路

上面这个例子还有一种桥接实现方式，可以自己试一下。

效果及实现要点：

桥接模式使用对象见的组合关系解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同路上的不同其次。
桥接模式有时候类似于多继承方案，但是多继承方案往往违背了SRP原则，复用性较差。桥接模式是比继承方案更好的解决方法。
桥接模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换而言之两个变化不会导致纵横交错的结果，并不一定要使用桥接模式。

使用场景

如果你不希望在抽象和实现部分采用固定的绑定关系，可以采用桥接模式，来把抽象和实现部分分开，然后在程序运行期间来动态的设置抽象部分需要用到的具体的实现，还可以动态切换具体的实现。
如果出现抽象部分和实现部分都应该可以扩展的情况，可以采用桥接模式，让抽象部分和实现部分可以独立的变化，从而可以灵活的进行单独扩展，而不是搅在一起，扩展一边会影响到另一边。
如果希望实现部分的修改，不会对客户产生影响，可以采用桥接模式，客户是面向抽象的接口在运行，实现部分的修改，可以独立于抽象部分，也就不会对客户产生影响了，也可以说对客户是透明的。
如果采用继承的实现方案，会导致产生很多子类，对于这种情况，可以考虑采用桥接模式，分析功能变化的原因，看看是否能分离成不同的纬度，然后通过桥接模式来分离它们，从而减少子类的数目。