桥接模式(Bridge Pattern)


模式动机

设想如果要绘制矩形、圆形、椭圆、正方形,我们至少需要 4 个形状类,但是如果绘制的图形需要具有不同的颜色,如红色、绿色、蓝色等,此时至少有如下两种设计方案:

  • 第一种设计方案是为每一种形状都提供一套各种颜色的版本。
  • 第二种设计方案是根据实际需要对形状和颜色进行组合

对于有两个变化维度(即两个变化的原因)的系统,采用方案二来进行设计系统中类的个数更少,且系统扩展更为方便。设计方案二即是桥接模式的应用。桥接模式将继承关系转换为关联关系,从而降低了类与类之间的耦合,减少了代码编写量。

模式定义

桥接模式(Bridge Pattern):将抽象和实现解耦,使得两者可以独立地变化。它是一种对象结构型模式,又称为桥梁模式。

模式角色

桥接模式包含如下角色:

  • Abstraction:抽象类角色
  • RefinedAbstraction:扩充抽象类
  • Implementor:实现化角色
  • ConcreteImplementor:具体实现化角色的实现类

UML 类图

桥接模式UML

代码示例

首先,是实现化角色Abstraction类:

/**
 * 实现化角色 Implementor.
 */
public interface Implementor {

    /**
     * 基本方法1.
     */
    void doSomething();

    /**
     * 基本方法2.
     */
    void doAnything();

}

然后,是各个具体的实现化角色类:

/**
 * ConcreteImplementor1.
 */
public class ConcreteImplementor1 implements Implementor {

    /**
     * 基本方法1.
     */
    @Override
    public void doSomething() {
        System.out.println("ConcreteImplementor1 的业务逻辑 doSomething.");
    }

    /**
     * 基本方法2.
     */
    @Override
    public void doAnything() {
        System.out.println("ConcreteImplementor1 的业务逻辑 doAnything.");
    }

}
/**
 * ConcreteImplementor2.
 */
public class ConcreteImplementor2 implements Implementor {

    /**
     * 基本方法1.
     */
    @Override
    public void doSomething() {
        System.out.println("ConcreteImplementor2 的业务逻辑 doSomething.");
    }

    /**
     * 基本方法2.
     */
    @Override
    public void doAnything() {
        System.out.println("ConcreteImplementor2 的业务逻辑 doAnything.");
    }

}

接下来,是抽象类角色Abstraction类:

package com.blinkfox.patterns.bridge;

/**
 * 抽象化角色 Abstraction.
 */
public abstract class Abstraction {

    /** 定义对实现化角色的引用. */
    private Implementor impl;

    /**
     * 构造方法.
     *
     * @param impl 实现类的实例
     */
    public Abstraction(Implementor impl) {
        this.impl = impl;
    }

    /**
     * impl 的 getter方法.
     *
     * @return impl
     */
    public Implementor getImpl() {
        return impl;
    }

    /**
     * 自身的请求处理方法.
     */
    public void request() {
        this.impl.doSomething();
    }

}

再次,是扩展的具体抽象化角色类RefinedAbstraction

/**
 * RefinedAbstraction.
 */
public class RefinedAbstraction extends Abstraction {

    /**
     * 构造方法.
     *
     * @param impl 实现类的实例
     */
    public RefinedAbstraction(Implementor impl) {
        super(impl);
    }

    /**
     * 覆盖后的请求处理方法.
     */
    @Override
    public void request() {
        System.out.println("RefinedAbstraction 开始做业务处理.");
        super.request();
        super.getImpl().doAnything();
    }

}

最后,是客户端场景类:

/**
 * Client.
 */
public class Client {

    /**
     * main方法.
     *
     * @param args 数组参数
     */
    public static void main(String[] args) {
        // 定义一个实现化角色和抽象化角色,并执行请求方法.
        Implementor impl = new ConcreteImplementor1();
        Abstraction abs = new RefinedAbstraction(impl);
        abs.request();
    }

}

模式分析

理解桥接模式,重点需要理解如何将抽象化(Abstraction)与实现化(Implementation)脱耦,使得二者可以独立地变化。

  • 抽象化:抽象化就是忽略一些信息,把不同的实体当作同样的实体对待。在面向对象中,将对象的共同性质抽取出来形成类的过程即为抽象化的过程。
  • 实现化:针对抽象化给出的具体实现,就是实现化,抽象化与实现化是一对互逆的概念,实现化产生的对象比抽象化更具体,是对抽象化事物的进一步具体化的产物。
  • 脱耦:脱耦就是将抽象化和实现化之间的耦合解脱开,或者说是将它们之间的强关联改换成弱关联,将两个角色之间的继承关系改为关联关系。桥接模式中的所谓脱耦,就是指在一个软件系统的抽象化和实现化之间使用关联关系(组合或者聚合关系)而不是继承关系,从而使两者可以相对独立地变化,这就是桥接模式的用意。

优点

桥接模式的优点:

  • 分离抽象接口及其实现部分。
  • 桥接模式有时类似于多继承方案,但是多继承方案违背了类的单一职责原则(即一个类只有一个变化的原因),复用性比较差,而且多继承结构中类的个数非常庞大,桥接模式是比多继承方案更好的解决方法。
  • 桥接模式提高了系统的可扩充性,在两个变化维度中任意扩展一个维度,都不需要修改原有系统。
  • 实现细节对客户透明,可以对用户隐藏实现细节。

缺点

桥接模式的缺点:

  • 桥接模式的引入会增加系统的理解与设计难度,由于聚合关联关系建立在抽象层,要求开发者针对抽象进行设计与编程。
  • 桥接模式要求正确识别出系统中两个独立变化的维度,因此其使用范围具有一定的局限性。

适用环境

在以下情况下可以使用桥接模式:

  • 如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的继承联系,通过桥接模式可以使它们在抽象层建立一个关联关系。
  • 抽象化角色和实现化角色可以以继承的方式独立扩展而互不影响,在程序运行时可以动态将一个抽象化子类的对象和一个实现化子类的对象进行组合,即系统需要对抽象化角色和实现化角色进行动态耦合。
  • 一个类存在两个独立变化的维度,且这两个维度都需要进行扩展。
  • 虽然在系统中使用继承是没有问题的,但是由于抽象化角色和具体化角色需要独立变化,设计要求需要独立管理这两者。
  • 对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统,桥接模式尤为适用。

模式应用

一个 Java 桌面软件总是带有所在操作系统的视感(LookAndFeel),如果一个 Java 软件是在 Unix 系统上开发的,那么开发人员看到的是Motif用户界面的视感;在 Windows 上面使用这个系统的用户看到的是 Windows 用户界面的视感;而一个在Macintosh上面使用的用户看到的则是Macintosh用户界面的视感,Java 语言是通过所谓的 Peer 架构做到这一点的。Java 为 AWT 中的每一个 GUI 构件都提供了一个 Peer 构件,在 AWT 中的 Peer 架构就使用了桥接模式。

模式扩展

适配器模式与桥接模式的联用:

桥接模式和适配器模式用于设计的不同阶段,桥接模式用于系统的初步设计,对于存在两个独立变化维度的类可以将其分为抽象化和实现化两个角色,使它们可以分别进行变化;而在初步设计完成之后,当发现系统与已有类无法协同工作时,可以采用适配器模式。但有时候在设计初期也需要考虑适配器模式,特别是那些涉及到大量第三方应用接口的情况。

总结

  • 桥接模式将抽象部分与它的实现部分分离,使它们都可以独立地变化。它是一种对象结构型模式。
  • 桥接模式包含如下四个角色:抽象类中定义了一个实现类接口类型的对象并可以维护该对象;扩充抽象类扩充由抽象类定义的接口,它实现了在抽象类中定义的抽象业务方法,在扩充抽象类中可以调用在实现类接口中定义的业务方法;实现类接口定义了实现类的接口,实现类接口仅提供基本操作,而抽象类定义的接口可能会做更多更复杂的操作;具体实现类实现了实现类接口并且具体实现它,在不同的具体实现类中提供基本操作的不同实现,在程序运行时,具体实现类对象将替换其父类对象,提供给客户端具体的业务操作方法。
  • 在桥接模式中,抽象化(Abstraction)与实现化(Implementation)脱耦,它们可以沿着各自的维度独立变化。
  • 桥接模式的主要优点是分离抽象接口及其实现部分,是比多继承方案更好的解决方法,桥接模式还提高了系统的可扩充性,在两个变化维度中任意扩展一个维度,都不需要修改原有系统,实现细节对客户透明,可以对用户隐藏实现细节;其主要缺点是增加系统的理解与设计难度,且识别出系统中两个独立变化的维度并不是一件容易的事情。
  • 桥接模式适用情况包括:需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的继承联系;抽象化角色和实现化角色可以以继承的方式独立扩展而互不影响;一个类存在两个独立变化的维度,且这两个维度都需要进行扩展;设计要求需要独立管理抽象化角色和具体化角色;不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统。

参考自:桥接模式


文章作者: 李小龙
版权声明: 本博客文章除特別声明外,均采用 CC BY-NC-ND 4.0 许可协议,转载请注明来源 悟尘记 - 李小龙的博客网站 !
评论
 上一篇
一、文章摘要 一、文章摘要
一个商用的区块链网络,随着业务的发展变化,经常需要动态的新增/移除组织,以满足业务/安全等管理需要。本文在既有组织/节点的基础上,新增一个组织两个节点。 F...
2019-06-04
下一篇 
适配器模式(Adapter Pattern) 适配器模式(Adapter Pattern)
模式动机 在软件开发中采用类似于电源适配器的设计和编码技巧被称为适配器模式。 通常情况下,客户端可以通过目标类的接口访问它所提供的服务。有时,现有的类可...
2018-12-12
  目录