0%

9.3.8 桥接模式

9.3.8 桥接模式

桥接模式是一种结构型模式,它主要应对的是:由于实际的需要,某个类具有两个或两个以上的维度变化,如果只是使用继承将无法实现这种需要,或者使得设计变得相当臃肿。
举例来说,假设现在需要为某个餐厅制造菜单,餐厅供应牛肉面、猪肉面……而且顾客可根据自己的口味选择是否添加辣椒。此时就产生了一个问题,如何应对这种变化:是否需要定义辣椒牛肉面、无辣牛肉面、辣椒猪肉面、无辣猪肉面4个子类?如果餐厅还供应羊肉面、韭菜面……·呢?如果添加辣椒时可选择无辣、微辣、中辣、重辣……风味呢?那程序岂非一直忙于定义子类?
为了解决这个问题,可以使用桥接模式,桥接模式的做法是把变化部分抽象出来,使变化部分与主类分离开来,从而将多个维度的变化彻底分离。最后提供一个管理类来组合不同维度上的变化,通过这种组合来满足业务的需要

程序示例

1
2
3
4
5
6
7
8
9
E:\workspace_QingLiangJiJavaEEQiYeYingYongShiZhang5\Bridge
└─src\
├─AbstractNoodle.java
├─BeefNoodle.java
├─Peppery.java
├─PepperySytle.java
├─PlainStyle.java
├─PorkyNoodle.java
└─Test.java

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

1
2
3
4
public interface Peppery
{
String style();
}

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

1
2
3
4
5
6
7
8
public class PepperySytle implements Peppery
{
// 实现"辣味"风格的方法
public String style()
{
return "辣味很重,很过瘾...";
}
}

下面一个实现类代表不添加辣椒的风格。

1
2
3
4
5
6
7
8
public class PlainStyle implements Peppery
{
// 实现"不辣"风格的方法
public String style()
{
return "味道清淡,很养胃...";
}
}

从上面的程序可以看出,该Peppery接口代表了面条在辣味风格这个维度上的变化,不论面条在该维度上有多少种变化,程序只需要为这几种变化分别提供实现类即可。对于系统而言,辣味风格这个维度上的变化是固定的,是程序必须面对的,程序使用桥接模式将辣味风格这个维度的变化分离出来了,避免与牛肉、猪肉材料风格这个维度的变化耦合在一起。
接着程序提供了一个AbstractNoodle抽象类,该抽象类将会持有一个Peppery属性,该属性代表该面条的辣味风格。程序通过AbstractNoodle组合一个Peppery对象,从而运行了面条在辣味风格这个维度上的变化;而AbstractNoodle本身可以包含很多实现类,不同实现类则代表了面条在材料风格这个维度上的变化。下面是AbstractNoodle类的代码。

1
2
3
4
5
6
7
8
9
10
11
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子类,该子类代表猪肉面。

1
2
3
4
5
6
7
8
9
10
11
12
public class PorkyNoodle extends AbstractNoodle
{
public PorkyNoodle(Peppery style)
{
super(style);
}
// 实现eat()抽象方法
public void eat()
{
System.out.println("这是一碗稍嫌油腻的猪肉面条。" + super.style.style());
}
}

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

1
2
3
4
5
6
7
8
9
10
11
12
public class BeefNoodle extends AbstractNoodle
{
public BeefNoodle(Peppery style)
{
super(style);
}
// 实现eat()抽象方法
public void eat()
{
System.out.println("这是一碗美味的牛肉面条。" + super.style.style());
}
}

PorkyNoodle.javaBeefMoodle.java中可以看出:AbstractNoodle的两个具体类实现eat()方法时,既组合了材料风格的变化,也组合了辣味风格的变化,从而可表现出两个维度上的变化。在桥接模式下这些接口和类之间的结构关系如图9.11所示。
这里有一张图片
下面提供一个主程序,可以分别产生辣椒牛肉面、无辣牛肉面、辣椒猪肉面、无辣猪肉面4种风格的面条。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class Test
{
public static void main(String[] args)
{
// 下面将得到“辣味”的牛肉面
AbstractNoodle noodle1 = new BeefNoodle(new PepperySytle());
noodle1.eat();
// 下面将得到“不辣”的牛肉面
AbstractNoodle noodle2 = new BeefNoodle(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框架,当你深入阅读其源代码时,你会发现这个框架处处充满了设计模式的应用场景。

原文链接: 9.3.8 桥接模式