桥接模式

桥接模式是一种结构型模式，它主要应对的是：由于实际的需要，某个类具有两个或两个以上的维度变化，如果只是使用继承将无法实现这种需要，或者使得设计变得相当臃肿。

举例来说，假设现在我们需要为某个餐厅制造菜单，餐厅供应牛肉面、猪肉面……，而且顾客可根据自己的口味选择是否添加辣椒。此时就产生了一个问题，我们如何来应对这种变化：我们是否需要定义辣椒牛肉面、无辣牛肉面、辣椒猪肉面、无辣猪肉面4个子类？如果餐厅还供应羊肉面、韭菜面……呢？如果添加辣椒时可选择无辣、微辣、中辣、重辣……风味呢？那程序岂非一直忙于定义子类？

为了解决这个问题，我们可以使用桥接模式，桥接模式的做法是把变化部分抽象出来，使变化部分与主类分离开来，从而将多个维度的变化彻底分离。最后提供一个管理类来组合不同维度上的变化，通过这种组合来满足业务的需要。

下面以一个简单的示例来示范桥接模式的使用。程序首先提供了一个Peppery接口，该接口代表了面条是否添加辣椒。程序如下：

程序清单：codes\09\9.3\Bridge\Peppery.java

public interface Peppery
{
String style();
}

接着程序为该接口提供两个实现类，第一个实现类代表辣椒的风格。程序如下：

程序清单：codes\09\9.3\Bridge\PepperySytle.java

public class PepperySytle implements Peppery
{
//实现"辣味"风格的方法
public String style()
{
return "辣味很重，很过瘾...";
}
}

下面一个实现类代表不添加辣椒的风格，程序如下：

程序清单：codes\09\9.3\Bridge\PlainStyle.java

public class PlainStyle implements Peppery
{
//实现"不辣"风格的方法
public String style()
{
return "味道清淡，很养胃...";
}
}

从上面程序可以看出，该Peppery接口代表了面条在辣味风格这个维度上的变化，不论面条在该维度上有多少种变化，程序只需要为这几种变化分别提供实现类即可。对于系统而言，辣味风格这个维度上的变化是固定的，程序必须面对的，程序使用桥接模式将辣味风格这个维度的变化分离出来了，避免与牛肉、猪肉材料风格这个维度的变化耦合在一起。

接着程序提供了一个AbstractNoodle抽象类，该抽象类将会持有一个Peppery属性，该属性代表该面条的辣味风格。程序通过AbstractNoodle组合一个Peppery对象，从而运行了面条在辣味风格这个维度上的变化；而AbstractNoodle本身可以包含很多实现类，不同实现类则代表了面条在材料风格这个维度上的变化。下面是AbstractNoodle类的代码。

程序清单：codes\09\9.3\Bridge\AbstractNoodle.java

public abstract class AbstractNoodle
{
//组合一个Peppery变量，用于将该维度的变化独立出来
protected Peppery style;
//每份Noodle必须组合一个Peppery对象
public AbstractNoodle(Peppery style)
{
this.style = style;
}
public abstract void eat();
}

正如上面程序中粗体字代码所示，上面的AbstractNoodle实例将会与一个Peppery实例组合，不同的AbstractNoodle实例与不同的Peppery实例组合，就可完成辣味风格、材料风格两个维度上变化的组合了。

 

 

 

由此可见，AbstractNoodle抽象类可以看做是一个桥梁，它被用来“桥接”面条的材料风格的改变与辣味风格的改变，使面条的特殊属性得到无绑定的扩充。

接下来为AbstractNoodle提供一个PorkyNoodle子类，该子类代表猪肉面。

程序清单：codes\09\9.3\Bridge\PorkyNoodle.java

public class PorkyNoodle extends AbstractNoodle
{
public PorkyNoodle(Peppery style)
{
super(style);
}
//实现eat()抽象方法
public void eat()
{
System.out.println("这是一碗稍嫌油腻的猪肉面条。"
+ super.style.style());
}
}

再提供一个BeefMoodle子类，该子类代表牛肉面。

程序清单：codes\09\9.3\Bridge\BeefMoodle.java

public class BeefMoodle extends AbstractNoodle
{
public BeefMoodle(Peppery style)
{
super(style);
}
//实现eat()抽象方法
public void eat()
{
System.out.println("这是一碗美味的牛肉面条。"
+ super.style.style());
}
}

从PorkyNoodle.java和BeefMoodle.java中可以看出：AbstractNoodle的两个具体类实现eat()方法时，既组合了材料风格的变化，也组合了辣味风格的变化，从而可表现出两个维度上的变化。桥接模式下这些接口和类之间的结构关系如图9.11所示。

 

图9.11  桥接模式的类图

下面提供一个主程序，可以分别产生辣椒牛肉面、无辣牛肉面、辣椒猪肉面、无辣猪肉面4种风格的面条。

程序清单：codes\09\9.3\Bridge\Test.java

public class Test
{
public static void main(String[] args) 
{
//下面将得到“辣味”的牛肉面
AbstractNoodle noodle1 = new BeefMoodle(
new PepperySytle());
noodle1.eat();
//下面将得到“不辣”的牛肉面
AbstractNoodle noodle2 = new BeefMoodle(
new PlainStyle());
noodle2.eat();
//下面将得到“辣味”的猪肉面
AbstractNoodle noodle3 = new PorkyNoodle(
new PepperySytle());
noodle3.eat();
//下面将得到“不辣”的猪肉面
AbstractNoodle noodle4 = new PorkyNoodle(
new PlainStyle());
noodle4.eat();
}
}

上面程序的main方法中得到了4种面条，这4种面条就满足了面条在两个维度上的变化，但程序结构又比较简洁。

桥接模式在Java EE架构中有非常广泛的用途，由于Java EE应用需要实现跨数据库的功能，程序为了在不同数据库之间迁移，因此系统需要在持久化技术这个维度上存在改变；除此之外，系统也需要在不同业务逻辑实现之间迁移，因此也需要在逻辑实现这个维度上存在改变，这正好符合桥接模式的使用场景。因此，Java EE应用都会推荐使用业务逻辑组件和DAO组件分离的结构，让DAO组件负责持久化技术这个维度上的改变，让业务逻辑组件负责业务逻辑实现这个维度上的改变。由此可见，Java EE应用中常见的DAO模式正是桥接模式的应用。

可能有读者会感到奇怪，刚才我们还提到用业务逻辑组件来包装DAO组件是门面模式，怎么现在又说这种方式是桥接模式呢？其实这两种说法都没有问题，称这种方式为门面模式，是从每个业务逻辑组件底层包装了多个DAO组件这个角度来看的，从这个角度来看，业务逻辑组件就是DAO组件的门面；如果从DAO组件的设计初衷来看，设计DAO组件是为了让应用在不同持久化技术之间自由切换，也就是分离系统在持久化技术这个维度上的变化，从这个角度来看，Java EE应用中分离出DAO组件本身就是遵循桥接模式的。

不要以为每段代码、每个应用只能使用一种设计模式！实际上，一个设计优良的项目，本身就是设计模式最好的教科书，例如Spring框架，当你深入阅读其源代码时，你会发现这个框架处处充满了设计模式的应用场景。

笔者在此处介绍设计模式，并不是为了让读者满足于设计模式的实现方式，而是希望读者能掌握设计模式的应用场景，能使用设计模式来解决实际开发问题。真正掌握设计模式的要求是：当进行系统开发时，无须刻意思索需要运用哪种设计模式；而是信手写来，而整个应用的设计充满灵性，大量设计模式应用其中。