在学习这个设计模式的时候，我是比较痛苦的。因为网上的很多教程虽然主题是桥（Bridge）,但是一直在说如何拆分，如何解耦。直到我真正理解桥接模式之后，才发现那些教程都背离了这一设计模式的名字---Bridge，即一个起到连接作用的物体。
桥接的是什么？
试想有这样一个类层次结构，它实现的是类的意义层面上的抽象：
另外还有一个接口层次结构，而它表示的则是从类的行为层面进行抽象：
为了让两者能够松耦合地运行在一起，通过在Shape中添加DrawingProgramming的实例的方式进行聚合，即实现了桥接模式：
桥接模式
一般来说，桥接模式可以概括为下图：
可以看到图中共有5个主要的概念：
- Client： 客户端，对类进行调用；
- Abstraction：抽象类，从类的实际含义角度出发，对其进行抽象，并包含一个Implementor的实例
- Implementor：实现者，一般是一个定义了类的各种行为的接口；
- RefinedAbstraction：细化类，扩展(extends)了Abstraction，从类的含义上进行结构的堆叠；
- ConcreteImplementor A&B：具体实现，即实现了Implementor中定义的方法，提供类的行为的具体内容。
其实看到这个图之后，有的人可能会提出异议：
为什么不直接将Implementor中定义的方法放入Abstraction，然后让RefinedAbstraction直接实现呢？
单一责任原则
单一责任原则（SRP：Single responsibility principle）又称单一职责原则，如果一个类承担的责任过多，就等于把这些责任耦合在一起了。一个责任的变化可能会影响这个类完成其他责任的能力。这种耦合会导致脆弱的设计，当发生变更时，设计会遭受到意想不到的破坏。
SRP正是桥接模式要维护的原则。试问如果真的将方法放入Abstraction后，它的子类将会为了实现放入父类的方法而绞尽脑汁，尽管很可能某个方法和某个子类没有任何关系；而如果不把大部分子类的行为方法抽象到父类中，又会导致类型之间的不兼容，引发了大量的instanceof海洋（instance of ocean）。
桥接模式的优点
使用桥接模式，主要是看中了它所带来的优点：
- 将类的含义层次和行为层次松耦合；
- 使整套API能够拥有两个维度的扩展链，提到了系统的独立性；
- 隐藏了更多的细节；
- 使用设计模式能够使其他开发维护者更容易理解。
使用范例
从下图中我们可以看出，Shape和DrawAPI很好地解耦了，Circle从类的含义出发进行了扩展，而RedCircle和GreenCircle从类的行为出发进行了接口的实现，两者互不影响，且通过一个聚合的关系，将两个维度松耦合到了一起。
