9.3.8 桥接模式
9.3.8 桥接模式
桥接模式是一种结构型模式,它主要应对的是:由于实际的需要,某个类具有两个或两个以上的维度变化,如果只是使用继承将无法实现这种需要,或者使得设计变得相当臃肿。
举例来说,假设现在需要为某个餐厅制造菜单,餐厅供应牛肉面、猪肉面……而且顾客可根据自己的口味选择是否添加辣椒。此时就产生了一个问题,如何应对这种变化:是否需要定义辣椒牛肉面、无辣牛肉面、辣椒猪肉面、无辣猪肉面4个子类?如果餐厅还供应羊肉面、韭菜面……·呢?如果添加辣椒时可选择无辣、微辣、中辣、重辣……风味呢?那程序岂非一直忙于定义子类?
为了解决这个问题,可以使用桥接模式,桥接模式的做法是把变化部分抽象出来,使变化部分与主类分离开来,从而将多个维度的变化彻底分离。最后提供一个管理类来组合不同维度上的变化,通过这种组合来满足业务的需要。
程序示例
1 | E:\workspace_QingLiangJiJavaEEQiYeYingYongShiZhang5\Bridge |
下面以一个简单的示例来示范桥接模式的使用。程序首先提供了一个Peppery
接口,该接口代表了面条是否添加辣椒。
1 | public interface Peppery |
接着程序为该接口提供两个实现类,第一个实现类代表辣椒的风格。
1 | public class PepperySytle implements Peppery |
下面一个实现类代表不添加辣椒的风格。
1 | public class PlainStyle implements Peppery |
从上面的程序可以看出,该Peppery
接口代表了面条在辣味风格这个维度上的变化,不论面条在该维度上有多少种变化,程序只需要为这几种变化分别提供实现类即可。对于系统而言,辣味风格这个维度上的变化是固定的,是程序必须面对的,程序使用桥接模式将辣味风格这个维度的变化分离出来了,避免与牛肉、猪肉材料风格这个维度的变化耦合在一起。
接着程序提供了一个AbstractNoodle
抽象类,该抽象类将会持有一个Peppery
属性,该属性代表该面条的辣味风格。程序通过AbstractNoodle
组合一个Peppery
对象,从而运行了面条在辣味风格这个维度上的变化;而AbstractNoodle
本身可以包含很多实现类,不同实现类则代表了面条在材料风格这个维度上的变化。下面是AbstractNoodle
类的代码。
1 | public abstract class AbstractNoodle |
正如上面的代码所示,上面的AbstractNoodle
实例将会与一个Peppery
实例组合,不同的AbstractNoodle
实例与不同的Peppery
实例组合,就可完成辣味风格、材料风格两个维度上变化的组合了。
由此可见, AbstractNoodle
抽象类可以看做是一个桥梁,它被用来”桥接”面条的材料风格的改变与辣味风格的改变,使面条的特殊属性得到无绑定的扩充。
接下来为AbstractNoodle
提供一个PorkyNoodle
子类,该子类代表猪肉面。
1 | public class PorkyNoodle extends AbstractNoodle |
再提供一个BeefMoodle
子类,该子类代表牛肉面。
1 | public class BeefNoodle extends AbstractNoodle |
从PorkyNoodle.java
和BeefMoodle.java
中可以看出:AbstractNoodle
的两个具体类实现eat()
方法时,既组合了材料风格的变化,也组合了辣味风格的变化,从而可表现出两个维度上的变化。在桥接模式下这些接口和类之间的结构关系如图9.11所示。
下面提供一个主程序,可以分别产生辣椒牛肉面、无辣牛肉面、辣椒猪肉面、无辣猪肉面4种风格的面条。
1 | public class Test |
上面程序的main()
方法中得到了4种面条,这4种面条就满足了面条在两个维度上的变化,但程序结构又比较简洁。
桥接模式在Java EE
架构中有非常广泛的用途,由于Java EE
应用需要实现跨数据库的功能,程序为了在不同数据库之间迁移,因此系统需要在持久化技术这个维度上存在改变;除此之外,系统也需要在不同业务逻辑实现之间迁移,因此也需要在逻辑实现这个维度上存在改变,这正好符合桥接模式的使用场景。因此, Java EE
应用都会推荐使用业务逻辑组件和DAO
组件分离的结构,让DAO
组件负责持久化技术这个维度上的改变,让业务逻辑组件负责业务逻辑实现这个维度上的改变。由此可见, Java EE
应用中常见的DAO
模式正是桥接模式的应用。
可能有读者会感到奇怪,刚才还提到用业务逻辑组件来包装DAO
组件是门面模式,怎么现在又说这种方式是桥接模式呢?其实这两种说法都没有问题,称这种方式为门面模式,是从每个业务逻辑组件底层包装了多个DAO
组件这个角度来看的,从这个角度来看,业务逻辑组件就是DAO
组件的门面;如果从DAO
组件的设计初衷来看,设计DAO
组件是为了让应用在不同持久化技术之间自由切换,也就是分离系统在持久化技术这个维度上的变化,从这个角度来看, Java EE
应用中分离出DAO
组件本身就是遵循桥接模式的
不要以为每段代码、每个应用只能使用一种设计模式!实际上,一个设计优良的项目,本身就是设计模式最好的教科书,例如Spring
框架,当你深入阅读其源代码时,你会发现这个框架处处充满了设计模式的应用场景。