简介
Decouple an abstraction from its implementation so that the two can vary independently.
解耦抽象和实现，使得两者可以独立的变化。
桥接模式（Bridge Pattern） 也称为 桥梁模式、接口(Interfce)模式 或 柄体（Handle and Body）模式，隶属对象结构型模式。
桥接模式 类似于多重继承方案，但是多重继承方案往往违背了类得单一职责原则，其复用性比较差，桥接模式 是比多重继承更好的替代方案。
桥接模式 的核心在于 解耦抽象和实现。
注：此处的 抽象 并不是指 抽象类 或 接口 这种高层概念，实现 也不是 继承 或 接口实现 。抽象 与 实现 其实指的是两种独立变化的维度。其中，抽象 包含 实现，因此，一个 抽象 类的变化可能涉及到多种维度的变化导致的。
主要解决
当一个类内部具备两种或多种变化维度时，使用 桥接模式 可以解耦这些变化的维度，使高层代码架构稳定。
优缺点
优点
- 抽象和实现分离：这是 桥接模式 的主要特点，也是避免使用 继承 的主要原因。使用 桥接模式，解耦了 抽象 和 实现，使得两者的变化不会对另一方产生影响，使得系统扩展性大大增强。
- 优秀的扩展能力：桥接模式 的出现就是为了解决多个独立变化的维度的耦合，其高层模块聚合关系已确定（稳定）。因此，无论是 抽象 变化还是 实现 变化，只要对其进行扩展即可，高层代码无需任何更改即可接收扩展。高层代码依赖抽象，严格遵循了 依赖倒置原则。
- 实现细节对客户透明：由于 桥接模式 在高层模块（抽象层）通过聚合关系构建了稳定的架构（封装）。因此，客户只需与高层模块交互，对 抽象 和 实现 的细节完全不需关注。
缺点
- 桥接模式 由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计与编程，因此会增加系统的理解与设计难度。
使用场景
- 一个类存在两个（或多个）独立变化的维度，且这两个维度都需要进行扩展；
- 不希望或不适合使用继承的场景；
注：桥接模式 的一个常用使用场景就是为了替换 继承。我们知道，继承 拥有很多优点，比如 抽象，封装，多态 等，父类封装共性，子类实现特性。继承 可以很好地帮助我们实现代码复用（封装）的功能，但是同时，这也是 继承 的一大缺点。因为父类拥有的方法，子类也会继承得到，无论子类需不需要，这说明了 继承 具备 强侵入性（父类代码侵入子类），同时会导致子类臃肿······因此，在设计模式中，有一个原则为：优先使用组合/聚合的方式，而不是继承。
但是，设计模式是死的，人是活的。很多时候，你分不清该使用 继承 还是 组合/聚合 或其他方式等，可以从 现实语义 进行思考，因为软件（代码）最终还是提供给现实生活中的人用的，是服务于人类社会的，软件（代码）是具备现实场景的，单你从纯代码角度无法看清问题时，现实角度可能会给你提供更加开阔的思路。
模式讲解
首先来看下 桥接模式 的通用 UML 类图：
从 UML 类图中，我们可以看到，桥接模式 主要包含四种角色：
- 抽象（Abstraction）：该类持有一个对 实现 角色的引用，抽象 角色中的方法需要 实现 角色来实现。抽象 角色一般为抽象类（构造函数规定子类要传入一个 实现 对象）；
- 修正抽象（RefinedAbstraction）：Abstraction 的具体实现，对 Abstraction 的方法进行完善和扩展；
- 实现（Implementor）：定义 实现 维度的基本操作，提供给 Abstraction 使用。该类一般为接口或抽象类；
- 具体实现（ConcreteImplementor）：Implementor 的具体实现；
下面是 桥接模式 的通用代码：
package com.yn.design_pattern.bridge.universal;
class Client {
public static void main(String[] args) {
// 来一个实现化角色
IImplementor imp = new ConcreteImplementor();
// 来一个抽象化角色，聚合实现
Abstraction abs = new RefinedAbstraction(imp);
// 执行操作
abs.operation();
}
// 抽象实现
interface IImplementor {
void operationImpl();
}
// 具体实现
static class ConcreteImplementor implements IImplementor {
@Override
public void operationImpl() {
System.out.println("I'm ConcreteImplementor A");
}
}
// 抽象
abstract static class Abstraction {
protected IImplementor mImplementor;
public Abstraction(IImplementor implementor) {
this.mImplementor = implementor;
}
public void operation() {
this.mImplementor.operationImpl();
}
}
// 修正抽象
static class RefinedAbstraction extends Abstraction {
public RefinedAbstraction(IImplementor implementor) {
super(implementor);
}
@Override
public void operation() {
super.operation();
System.out.println("refined operation");
}
}
}
举个例子
下面给个示例，让我们能更好地理解 桥接模式。
例子：我们去咖啡馆喝咖啡，一般有4种选择：大杯加糖，大杯不加糖，小杯加糖，小杯不加糖。那么怎样用代码模拟选择咖啡呢？
分析：按上面的例子，很简单，咖啡就只有4种类型，因此我们建立一个“大杯加糖类”，“大杯不加糖类”，“小杯加糖类“，”小杯不加糖类“就可以覆盖上面例子所列举的咖啡了。但是，这样子的话咖啡杯和味道（糖）就耦合在一起了，后续如果有其他形式的咖啡，我们只能采用继承修改的方式扩展，继承类之间存在冗余部分，因此并不是很好的处理方案。
我们再回顾上面的例子，一杯咖啡包含两种选择：大小杯，有无糖（味道）。也就是通过这两个维度就可以决定一杯咖啡。涉及多个独立维度，我们很清楚应该使用 桥接模式。这里有两个独立维度：大小杯，有无糖（味道）。按 桥接模式 来说，应该有两个 实现：大小杯，有无糖（味道）。但是两个 实现 有点冗余，完全可以把 “大小杯” 这个维度归并到咖啡本身属性中，从而这个例子的维度变成：咖啡大小杯，有无糖（味道）。
代码如下所示：
package com.yn.design_pattern.bridge.exam;
class Client {
public static void main(String[] args) {
// 选择咖啡味道：原味
ICoffeeFlavor flavor = new PlainFlavor();
// 选择大杯咖啡
Coffee coffee = new LargeCoffee(flavor);
// 选择完毕：大杯咖啡：原味
coffee.makeCoffee();
// 大杯咖啡：加糖
new LargeCoffee(new SugarFlavor()).makeCoffee();
// 小杯咖啡：原味
new SmallCoffee(new PlainFlavor()).makeCoffee();
// 小杯咖啡：加糖
new SmallCoffee(new SugarFlavor()).makeCoffee();
}
// Implementor:有无糖
interface ICoffeeFlavor {
String addWhat();
}
// ConcreteImplementor：原味
static class PlainFlavor implements ICoffeeFlavor {
@Override
public String addWhat() {
return "原味";
}
}
// ConcreteImplementor：加糖
static class SugarFlavor implements ICoffeeFlavor {
@Override
public String addWhat() {
return "加糖";
}
}
// Abstraction：咖啡
static abstract class Coffee {
protected ICoffeeFlavor mFlavor;
public Coffee(ICoffeeFlavor flavor) {
this.mFlavor = flavor;
}
public abstract void makeCoffee();
}
// RefinedAbstraction：大杯咖啡
static class LargeCoffee extends Coffee {
public LargeCoffee(ICoffeeFlavor flavor) {
super(flavor);
}
@Override
public void makeCoffee() {
System.out.println("大杯咖啡: " + this.mFlavor.addWhat());
}
}
// RefinedAbstraction：小杯咖啡
static class SmallCoffee extends Coffee {
public SmallCoffee(ICoffeeFlavor flavor) {
super(flavor);
}
@Override
public void makeCoffee() {
System.out.println("小杯咖啡：" + this.mFlavor.addWhat());
}
}
}
上面这个例子，我们采用 桥接模式 解耦了 “咖啡大小杯” 和 “有无糖（味道）” 这两个独立变化的维度。后续如果咖啡馆提供更多的服务，比如中杯咖啡，那么直接新建一个中杯类继承Coffee即可；如果是咖啡味道更改，比如可以加牛奶，蜂蜜等，那么同样只需新建一个类实现ICoffeeFlavor即可。
通过上面的例子，我们能很好地感知到 桥接模式 遵循了设计模式 里氏替换原则 和 依赖倒置原则，最终实现了 开闭原则，对修改关闭，对扩展开放。
