桥接模式

核心意图：
将抽象部分和实现部分分离，使它们都可以独立的变化。解决了继承关系的复杂性。
该模式的目标是通过把高层的抽象和底层的实现分开，分别构建自己的类层次结构，并通过实现部分的接口将两部分进行桥接，从而达到高层抽象和底层实现可以独立的方便扩展的目的。其核心是分离，和委托。

一句话

将抽象和行为划分开来,各自独立,但能动态的组合。

在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。
意图:
　　　将抽象部分与实现部分分离，使它们都可以独立的变化。
                                                                    ——《设计模式》GOF 

 

生活中的例子

比如，一杯咖啡为例,子类实现类为四个：中杯加奶、大杯加奶、中杯不加奶、大杯不加奶。这四个类实际是两个角色的组合：抽象和行为，其中抽象为：中杯和大杯；行为为：加奶不加奶（如加橙汁加苹果汁），这就是Bridge模式。

 

核心代码

public abstract class Coffee {
 CoffeeImp coffeeImp;

 public void setCoffeeImp(CoffeeImp coffeeImp) {
  this.coffeeImp = coffeeImp;
 }

 public CoffeeImp getCoffeeImp() {
  return this.coffeeImp;
 }

 

其中CoffeeImp 是加不加奶的行为接口,看其代码如下:

 

public abstract class CoffeeImp
{
　　public abstract void pourCoffeeImp();
}

 public abstract void pourCoffee();
}

 

 

1．Bridge模式使用“对象间的组合关系”解耦了抽象和行为之间固有的绑定关系，使得抽象和行为可以沿着各自的维度来变化。

2．所谓抽象和行为沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同平台上的不同型号。

3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。

4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。

适用性

在以下的情况下应当使用桥梁模式：

1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。

2．设计要求行为化角色的任何改变不应当影响客户端，或者说行为化角色的改变对客户端是完全透明的。

3．一个构件有多于一个的抽象化角色和行为化角色，系统需要它们之间进行动态耦合。

4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

总结

Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。目前有一种流行的设计模式，个人认为它来源与Bridge的创意，它就是IoC，它的大名鼎鼎的容器是Spring.