学习：java设计模式—Bridge模式

学习：java设计模式—Bridge模式

一、引子

下面是吕振宇大牛的一个例子，个人觉得挺好的，有助于理解Bridge模式的设计目的：

设想要绘制一幅图画，蓝天、白云、绿树、小鸟，如果画面尺寸很大，那么用蜡笔绘制就会遇到点麻烦。毕竟细细的蜡笔要涂出一片蓝天，是有些麻烦。如果 有可能，最好有套大号蜡笔，粗粗的蜡笔很快能涂抹完成。至于色彩吗，最好每种颜色来支粗的，除了蓝天还有绿地呢。这样，如果一套12种颜色的蜡笔，我们需 要两套24支，同种颜色的一粗一细。呵呵，画还没画，开始做梦了：要是再有一套中号蜡笔就更好了，这样，不多不少总共36支蜡笔。

 

再看看毛笔这一边，居然如此简陋：一套水彩12色，外加大中小三支毛笔。你可别小瞧这"简陋"的组合，画蓝天用大毛笔，画小鸟用小毛笔，各具特色。

 

呵 呵，您是不是已经看出来了，不错，我今天要说的就是Bridge模式。为了一幅画，我们需要准备36支型号不同的蜡笔，而改用毛笔三支就够了，当然还要搭 配上12种颜料。通过Bridge模式，我们把乘法运算3×12＝36改为了加法运算3＋12＝15，这一改进可不小。那么我们这里蜡笔和毛笔到底有什么 区别呢？

实际上，蜡笔和毛笔的关键一个区别就在于笔和颜色是否能够分离。【GOF95】桥梁模式的用意是"将抽象化 (Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。关键就在于能否脱耦。蜡笔的颜色和蜡笔本身是分不 开的，所以就造成必须使用36支色彩、大小各异的蜡笔来绘制图画。而毛笔与颜料能够很好的脱耦，各自独立变化，便简化了操作。在这里，抽象层面的概念 是："毛笔用颜料作画"，而在实现时，毛笔有大中小三号，颜料有红绿蓝等12种，于是便可出现3×12种组合。每个参与者（毛笔与颜料）都可以在自己的自 由度上随意转换。

蜡笔由于无法将笔与颜色分离，造成笔与颜色两个自由度无法单独变化，使得只有创建36种对象才能完成任务。Bridge 模式将继承关系转换为组合关系，从而降低了系统间的耦合，减少了代码编写量。但这仅仅是Bridge模式带来的众多好处的一部分，更多层面的内容，请参考 《设计模式（16）－Bridge Pattern》。

桥梁模式的用意

【GOF95】在提出桥梁模式的时候指出，桥梁模式的用意是"将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。这句话有三个关键词，也就是抽象化、实现化和脱耦。

抽象化

存在于多个实体中的共同的概念性联系，就是抽象化。作为一个过程，抽象化就是忽略一些信息，从而把不同的实体当做同样的实体对待【LISKOV94】。

实现化

抽象化给出的具体实现，就是实现化。

脱耦

所谓耦合，就是两个实体的行为的某种强关联。而将它们的强关联去掉，就是耦合的解脱，或称脱耦。在这里，脱耦是指将抽象化和实现化之间的耦合解脱开，或者说是将它们之间的强关联改换成弱关联。

将两个角色之间的继承关系改为聚合关系，就是将它们之间的强关联改换成为弱关联。因此，桥梁模式中的所谓脱耦，就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以相对独立地变化。这就是桥梁模式的用意。

二、 桥梁模式的结构

桥梁模式【GOF95】是对象的结构模式，又称为柄体(Handle and Body)模式或接口(Interface)模式。

下图所示就是一个实现了桥梁模式的示意性系统的结构图。

可以看出，这个系统含有两个等级结构，也就是：

• 由抽象化角色和修正抽象化角色组成的抽象化等级结构。
• 由实现化角色和两个具体实现化角色所组成的实现化等级结构。

桥梁模式所涉及的角色有：

• 抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。
• 修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。
• 实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。
• 具体实现化(Concrete Implementor)角色：这个角色给出实现化角色接口的具体实现。

三、代码示例

Bridge定义 :
将抽象和行为划分开来,各自独立,但能动态的结合.

为什么使用?
通常,当一个抽象类或接口有多个具体实现(concrete subclass),这些concrete之间关系可能有以下两种:
1. 这多个具体实现之间恰好是并列的,如前面举例,打桩,有两个concrete class:方形桩和圆形桩;这两个形状上的桩是并列的,没有概念上的重复,那么我们只要使用继承就可以了.

2.实际应用上,常常有可能在这多个concrete class之间有概念上重叠.那么需要我们把抽象共同部分和行为共同部分各自独立开来,原来是准备放在一个接口里,现在需要设计两个接口,分别放置抽象和行为.

例如,一杯咖啡为例,有中杯和大杯之分,同时还有加奶 不加奶之分. 如果用单纯的继承,这四个具体实现(中杯 大杯 加奶 不加奶)之间有概念重叠,因为有中杯加奶,也有中杯不加奶, 如果再在中杯这一层再实现两个继承,很显然混乱,扩展性极差.那我们使用Bridge模式来实现它.

如何实现?
以上面提到的咖啡 为例. 我们原来打算只设计一个接口(抽象类),使用Bridge模式后,我们需要将抽象和行为分开,加奶和不加奶属于行为,我们将它们抽象成一个专门的行为接口.

先看看抽象部分的接口代码:

package com.pattern.bridge;

public abstract class Coffee
{
    // CoffeeImp(行为)的引用
    private CoffeeImp coffeeImp;

    public CoffeeImp getCoffeeImp()
    {
        return coffeeImp;
    }

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

    abstract void pourCoffee();
}

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

package com.pattern.bridge;

/*******************************************************************************
 * 咖啡的行为接口
 * 
 * @author zdw
 * 
 */
public abstract class CoffeeImp
{
    // 冲咖啡
    public abstract void pourCoffeeImp();
}

现在我们有了两个抽象类,下面我们分别对其进行继承,实现concrete class:

package com.pattern.bridge;
/**
 *  中杯
 * @author zdw
 *
 */
public class MediumCoffee extends Coffee
{

    @Override
    void pourCoffee()
    {
        //我们以重复次数来说明是冲中杯还是大杯 ,重复2次是中杯
        for(int i = 0; i < 2; i ++)
        {
            this.getCoffeeImp().pourCoffeeImp();
        }
    }

}

 

package com.pattern.bridge;
/**
 * 大杯
 * @author zdw
 *
 */
public class SuperSizeCoffee extends Coffee
{

    @Override
    void pourCoffee()
    {
        for(int i = 0; i < 3; i ++)
        {
            this.getCoffeeImp().pourCoffeeImp();
        }
    }

}

上面分别是中杯和大杯的具体实现.下面再对行为CoffeeImp进行继承:

package com.pattern.bridge;
/**
 * 加牛奶行为
 * @author zdw
 *
 */
public class MilkCoffeeImp extends CoffeeImp
{

    @Override
    public void pourCoffeeImp()
    {
        System.out.println("加了牛奶的咖啡!");
    }

}

package com.pattern.bridge;
/**
 * 未加牛奶
 * @author zdw
 *
 */
public class FragrantCoffeeImp extends CoffeeImp
{

    @Override
    public void pourCoffeeImp()
    {
        System.out.println("未加牛奶的咖啡!");
    }

}

Bridge模式的基本框架我们已经搭好了,别忘记定义中还有一句:动态结合,我们现在可以喝到至少四种咖啡:
1.中杯加奶
2.中杯不加奶
3.大杯加奶
4.大杯不加奶

看看是如何动态结合的:

package com.pattern.bridge;

public class Client
{
    public static void main(String[] args)
    {
        //牛奶
        CoffeeImp coffeeImp = new MilkCoffeeImp();
        //未加牛奶
        CoffeeImp coffeeImp2 = new FragrantCoffeeImp();
        
        System.out.println("中杯");
        //中杯加奶(二次)
        Coffee coffee = new MediumCoffee();
        coffee.setCoffeeImp(coffeeImp);
        coffee.pourCoffee();
        System.out.println("***************中杯未加奶");
        coffee.setCoffeeImp(coffeeImp2);
        coffee.pourCoffee();
        
        System.out.println("***************大杯");
        //大杯加奶(三次)
        coffee = new SuperSizeCoffee();
        coffee.setCoffeeImp(coffeeImp);
        coffee.pourCoffee();
        System.out.println("**************大杯未加奶");
        //设置为未加奶
        coffee.setCoffeeImp(coffeeImp2);
        coffee.pourCoffee();
        
        
    }
}

注意: Bridge模式的执行类如CoffeeImp和Coffee是一对一的关系, 正确创建CoffeeImp是该模式的关键,

Bridge模式在EJB中的应用
EJB中有一个Data Access Object (DAO)模式,这是将商业逻辑和具体数据资源分开的,因为不同的数据库有不同的数据库操作.将操作不同数据库的行为独立抽象成一个行为接口DAO.如下:

1.Business Object (类似Coffee)

实现一些抽象的商业操作:如寻找一个用户下所有的订单

涉及数据库操作都使用DAOImplementor.

2.Data Access Object (类似CoffeeImp)

一些抽象的对数据库资源操作

3.DAOImplementor
 如OrderDAOCS, OrderDAOOracle, OrderDAOSybase(类似MilkCoffeeImp FragrantCoffeeImp)

具体的数据库操作,如"INSERT INTO "等语句,OrderDAOOracle是Oracle OrderDAOSybase是Sybase数据库.

4.数据库 (Cloudscape, Oracle, or Sybase database via JDBC API)

UML类图如下:

EG:当一个类的子类需要扩展时，如果要在两个维度进行扩展，那么就可以使用Bridge模式。