漫谈桥接模式

定义与目的

桥接模式（Bridge Pattern）将抽象部分与具体实现部分分离，使它们可以独立变化。
桥接模式也被称为桥梁模式( Bridge Design Pattern)、接口(Interface)模式或者柄体（Handle and Body）模式。

原文：Decouple an abstraction from its implementation so that the two can vary independently.

在桥接模式中的抽象不是指抽象类和接口这些高层概念，实现也不是指对抽象类的继承或接口的实现。
在《设计模式之美》中有一种的解释方式：

定义中的“抽象”，指的并非“抽象类”或“接口”，而是被抽象出来的一套“类库”，它只包含骨架代码，真正的业务逻辑需要委派给定义中的“实现”来完成。 定义中的“实现”，也并非“接口的实现类”，而是一套独立的“类库”。 “抽象”和“实现”独立开发，通过对象之间的组合关系，组装在一起

在很多设计模式书中还有一种简单的解释：当一个类内部具有两种（或多种）变化维度时，通过组合的方式可以解耦这些变化的维度，让其独立进行扩展。
在这种理解中，将类中存在的多种变化维度当作了抽象，将对这些变化维度的扩展当作实现。这种理解有些类似“组合优于继承”的设计原则。

应用场景

Java中的JDBC 驱动本身是一个桥接模式的典型。这里抽象是JDBC本身，它指定了Java中数据库操作的一套标准，具体实现是MySQL、Oracle等驱动。JDBC 和 Driver 独立开发，通过对象之间的组合关系，组装在一起。JDBC 的所有逻辑操作，最终都委托给 具体 Driver 来执行。
基于第二种解释，可以整理处如下使用场景：

1. 抽象与具体实现之间需要增加更多灵活性的场景。
2. 一个类存在两种（或多种）变化维度，这些维度需要独立扩展的时候。
3. 不希望使用继承，或者因为多层继承导致系统类的个数剧增的时候。

UML类图

第一种更像是一组类负责抽象，另一种组负责实现，从而实现桥接。这里简单描述下基于第二种理解的UML图：

由上图可见，桥接模式一般包括4个角色：

1. 抽象(Abstraction)：该类持有一个实现角色的引用，抽象角色中的方法需要实现角色来实现。抽象角色一般为抽象类（构造函数强制子类需要传入一个实现对象）。

通用写法

总结

优点

缺点