桥梁模式(Bridge Pattern)

  桥梁模式是对象的结构模式。又称为柄体(Handle and Body)模式或接口(Interface)模式。桥梁模式的用意是“将抽象化(Abstraction)与实现化(Implementation)脱耦,使得二者可以独立地变化”。

桥梁模式的用意

  桥梁模式虽然不是一个使用频率很高的模式,但是熟悉这个模式对于理解面向对象的设计原则,包括“开-闭”原则以及组合/聚合复用原则都很有帮助。理解好这两个原则,有助于形成正确的设计思想和培养良好的设计风格。桥梁模式的用意是“将抽象化(Abstraction)与实现化(Implementation)脱耦,使得二者可以独立地变化”。这句话很短,但是第一次读到这句话的人很可能都会思考良久而不解其意。这句话有三个关键词,也就是抽象化、实现化和脱耦。理解这三个词所代表的概念是理解桥梁模式用意的关键。

  • 抽象化。从众多的事物中抽取出共同的、本质性的特征,而舍弃其非本质的特征,就是抽象化。例如苹果、香蕉、生梨、 桃子等,它们共同的特性就是水果。得出水果概念的过程,就是一个抽象化的过程。要抽象,就必须进行比较,没有比较就无法找到在本质上共同的部分。共同特征是指那些能把一类事物与他类事物区分开来的特征,这些具有区分作用的特征又称本质特征。因此抽取事物的共同特征就是抽取事物的本质特征,舍弃非本质的特征。 所以抽象化的过程也是一个裁剪的过程。在抽象时,同与不同,决定于从什么角度上来抽象。抽象的角度取决于分析问题的目的。通常情况下,一组对象如果具有相同的特征,那么它们就可以通过一个共同的类来描述。如果一些类具有相同的特征,往往可以通过一个共同的抽象类来描述。
  • 实现化。抽象化给出的具体实现,就是实现化。一个类的实例就是这个类的实例化,一个具体子类是它的抽象超类的实例化。
  • 脱耦。所谓耦合,就是两个实体的行为的某种强关联。而将它们的强关联去掉,就是耦合的解脱,或称脱耦。在这里,脱耦是指将抽象化和实现化之间的耦合解脱开,或者说是将它们之间的强关联改换成弱关联。

  所谓强关联,就是在编译时期已经确定的,无法在运行时期动态改变的关联;所谓弱关联,就是可以动态地确定并且可以在运行时期动态地改变的关联。显然,在Java语言中,继承关系是强关联,而聚合关系是弱关联。将两个角色之间的继承关系改为聚合关系,就是将它们之间的强关联改换成为弱关联。因此,桥梁模式中的所谓脱耦,就是指在一个软件系统的抽象化和实现化之间使用聚合关系而不是继承关系,从而使两者可以相对独立地变化。这就是桥梁模式的用意。

桥梁模式的结构

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

  可以看出,这个系统含有两个等级结构:

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

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

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

  抽象化角色就像是一个水杯的手柄,而实现化角色和具体实现化角色就像是水杯的杯身。手柄控制杯身,这就是此模式别名“柄体”的来源。对象是对行为的封装,而行为是由方法实现的。在这个示意性系统里,抽象化等级结构中的类封装了operation()方法;而实现化等级结构中的类封装的是operationImpl()方法。当然,在实际的系统中往往会有多于一个的方法。抽象化等级结构中的方法通过向对应的实现化对象的委派实现自己的功能,这意味着抽象化角色可以通过向不同的实现化对象委派,来达到动态地转换自己的功能的目的。

源代码

//抽象化角色类,它声明了一个方法operation(),并给出了它的实现。这个实现是通过向实现化对象的委派(调用operationImpl()方法)实现的。
public abstract class Abstraction {
    protected Implementor impl;
    public Abstraction(Implementor impl){
        this.impl = impl;
    }
    //示例方法
    public void operation(){
        impl.operationImpl();
    }
}  

//修正抽象化角色
public class RefinedAbstraction extends Abstraction {
    public RefinedAbstraction(Implementor impl) {
        super(impl);
    }
    //其他的操作方法
    public void otherOperation(){
    }
}
//实现化角色
public abstract class Implementor {
    /**
     * 示例方法,实现抽象部分需要的某些具体功能
     */
    public abstract void operationImpl();
}  

//具体实现化角色
public class ConcreteImplementorA extends Implementor {
    @Override
    public void operationImpl() {
        //具体操作
    }
}  

public class ConcreteImplementorB extends Implementor {
    @Override
    public void operationImpl() {
        //具体操作
    }
}  

  一般而言,实现化角色中的每个方法都应当有一个抽象化角色中的某一个方法与之对应,但是反过来则不一定。换言之,抽象化角色的接口比实现化角色的接口宽。抽象化角色除了提供与实现化角色相关的方法之外,还有可能提供其他的方法;而实现化角色则往往仅为实现抽象化角色的相关行为而存在。

使用场景

  考虑这样一个实际的业务功能:发送提示消息。基本上所有带业务流程处理的系统都会有这样的功能,比如OA上有尚未处理完毕的文件,需要发送一条消息提示他。从业务上看,消息又分成普通消息、加急消息和特急消息多种,不同的消息类型,业务功能处理是不一样的,比如加急消息是在消息上添加加急,而特急消息除了添加特急外,还会做一条催促的记录,多久不完成会继续催促;从发送消息的手段上看,又有系统内短消息、手机短信息、邮件等。

使用桥梁模式来解决问题

  根据业务的功能要求,业务的变化具有两个维度,一个维度是抽象的消息,包括普通消息、加急消息和特急消息,这几个抽象的消息本身就具有一定的关系,加急消息和特急消息会扩展普通消息;另一个维度是在具体的消息发送方式上,包括系统内短消息、邮件和手机短消息,这几个方式是平等的,可被切换的方式。

  现在出现问题的根本原因,就在于消息的抽象和实现是混杂在一起的,这就导致了一个纬度的变化会引起另一个纬度进行相应的变化,从而使得程序扩展起来非常困难。要想解决这个问题,就必须把这两个纬度分开,也就是将抽象部分和实现部分分开,让它们相互独立,这样就可以实现独立的变化,使扩展变得简单。抽象部分就是各个消息的类型所对应的功能,而实现部分就是各种发送消息的方式。按照桥梁模式的结构,给抽象部分和实现部分分别定义接口,然后分别实现它们就可以了。

源代码

//@类说明 :抽象消息类
public abstract class AbstractMessage {
    // 持有一个实现部分的对象
    MessageImplementor impl;
    // 构造方法,传入实现部分的对象
    public AbstractMessage(MessageImplementor impl) {
        this.impl = impl;
    }    

    //发送消息,委派给实现部分的方法
      public void sendMessage(String message, String toUser) {
        this.impl.send(message, toUser);
    }
}   

//@类说明 :普通消息类
public class CommonMessage extends AbstractMessage {
    public CommonMessage(MessageImplementor impl) {
        super(impl);
    }
    @Override
    public void sendMessage(String message, String toUser) {
        // 对于普通消息,直接调用父类方法,发送消息即可
        super.sendMessage(message, toUser);
    }
}  

//@类说明 :加急消息类
public class UrgencyMessage extends AbstractMessage {
    public UrgencyMessage(MessageImplementor impl) {
        super(impl);
    }
    @Override
    public void sendMessage(String message, String toUser) {
        message = "加急:" + message;
        super.sendMessage(message, toUser);
    }
    //扩展自己的新功能,监控某消息的处理状态
    public Object watch(String messageId) {
       // 根据消息id获取消息的状态,组织成监控的数据对象,然后返回
        return null;
    }
}   

//@类说明 :实现发送消息的统一接口
public interface MessageImplementor {
     public void send(String message, String toUser);
}  

//@类说明 :系统内短消息的实现类
public class MessageSMS implements MessageImplementor {
    @Override
    public void send(String message, String toUser) {
        System.out.println("使用系统内短消息的方法,发送消息‘" + message + "‘给" + toUser);
    }
}   

//@类说明 :邮件短消息的实现类
 public class MessageEmail implements MessageImplementor {
    @Override
    public void send(String message, String toUser) {
        System.out.println("使用邮件短消息的方法,发送消息‘" + mes  sage + "‘给" + toUser);
    }
}  

//@类说明 :客户端类
public class Client {
    public static void main(String[] args) {
        // 创建具体的实现对象
        MessageImplementor impl = new MessageSMS();
        // 创建普通消息对象
        AbstractMessage message = new CommonMessage(impl);
        message.sendMessage("加班申请速批", "李总");
        // 将实现方式切换成邮件,再次发送
        impl = new MessageEmail();
        // 创建加急消息对象
        message = new UrgencyMessage(impl);
        message.sendMessage("加班申请速批", "李总");
    }
}  

  观察上面的例子会发现,采用桥梁模式来实现,抽象部分和实现部分分离开了,可以相互独立的变化,而不会相互影响。因此在抽象部分添加新的消息处理(特急消息),对发送消息的实现部分是没有影响的;反过来增加发送消息的方式(手机短消息),对消息处理部分也是没有影响的。

桥梁模式的优点

  • 分离抽象和实现部分。桥梁模式分离了抽象部分和实现部分,从而极大地提供了系统的灵活性。让抽象部分和实现部分独立出来,分别定义接口,这有助于对系统进行分层,从而产生更好的结构化的系统。
  • 更好的扩展性。桥梁模式使得抽象部分和实现部分可以分别独立地扩展,而不会相互影响,从而大大提高了系统的可扩展性。

桥梁模式在Java中的使用

  桥梁模式在Java应用中的一个非常典型的例子就是JDBC驱动器。JDBC为所有的关系型数据库提供一个通用的界面。一个应用系统动态地选择一个合适的驱动器,然后通过驱动器向数据库引擎发出指令。这个过程就是将抽象角色的行为委派给实现角色的过程。抽象角色可以针对任何数据库引擎发出查询指令,因为抽象角色并不直接与数据库引擎打交道,JDBC驱动器负责这个底层的工作。由于JDBC驱动器的存在,应用系统可以不依赖于数据库引擎的细节而独立地演化;同时数据库引擎也可以独立于应用系统的细节而独立的演化。两个独立的等级结构如下图所示,左边是JDBC API的等级结构,右边是JDBC驱动器的等级结构。应用程序是建立在JDBC API的基础之上的。

  应用系统作为一个等级结构,与JDBC驱动器这个等级结构是相对独立的,它们之间没有静态的强关联。应用系统通过委派与JDBC驱动器相互作用,这是一个桥梁模式的例子。JDBC的这种架构,把抽象部分和具体部分分离开来,从而使得抽象部分和具体部分都可以独立地扩展。对于应用程序而言,只要选用不同的驱动,就可以让程序操作不同的数据库,而无需更改应用程序,从而实现在不同的数据库上移植;对于驱动程序而言,为数据库实现不同的驱动程序,并不会影响应用程序。

时间: 2024-10-21 20:18:58

桥梁模式(Bridge Pattern)的相关文章

变脸不变质的桥梁模式(Bridge Pattern)

有一哥们是搞山寨货的,什么流行就搞什么.自己有个厂子,前些时间服装挣钱,就生产衣服,现在搞手机挣钱,搞手机,这哥们很聪明,就换了个产品,工人,厂房都不变.他是怎么做到的?用类图来模拟一下: 由类图可以看出这哥现有两家公司,一个搞房地产,一个搞山寨货(phone),房地产是长久渠道,山寨随时可能变更. 用PHP来实现: <?php abstract class Corp { private $product; public function __construct( Product $produc

如何让孩子爱上设计模式 ——10.桥接模式(Bridge Pattern)

如何让孩子爱上设计模式 --10.桥接模式(Bridge Pattern) 我有故事,你有酒吗?这年头写个技术文不讲个故事都不行,行,我讲: 还有发现很多的技术博文都开始有喜欢往文中插入几个表情的趋势了, 但是你真的插的姿势对了吗?这种事情不是随便插的,来来来,给你 见识下如何在适当的场景插入适当的表情以让读者感觉到易可赛艇, 本文以讲故事插表情为主,讲述桥接模式为辅,多图预警, 简书上排版可能有些问题,最佳排版可见: https://www.zybuluo.com/coder-pig/note

二十四种设计模式:桥接模式(Bridge Pattern)

桥接模式(Bridge Pattern) 介绍将抽象部分与它的实现部分分离,使它们都可以独立地变化. 示例有一个Message实体类,对它的操作有Insert()和Get()方法,现在使这些操作的抽象部分和实现部分分离. MessageModel using System; using System.Collections.Generic; using System.Text; namespace Pattern.Bridge { /// <summary> /// Message实体类 //

【设计模式】桥接模式 Bridge Pattern

开篇还是引用吕振宇老师的那篇经典的文章<设计模式随笔-蜡笔与毛笔的故事>.这个真是太经典了,没有比这个例子能更好的阐明桥接模式了,这里我就直接盗来用了. 现在市面上卖的蜡笔很多,各种型号,各种颜色种类繁多, 假如一盒蜡笔有24种颜色,那么它能涂抹出24种不同的颜色来,蜡笔型号是固定的,如果想画出各种线条那么就要购买不同型号的蜡笔,假如我们要涂抹出粗,中,细三种线条,那么我们就要买3盒粗,中,细型号的蜡笔才能满足需求,那么就是3盒*24色=72只蜡笔.假如使用毛笔来作画,我们需要准备3只粗,中,

说说设计模式~桥梁模式(Bridge)

返回目录 在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种“多维度的变化”?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度?这就要使用Bridge模式. 意图 [GOF95]在提出桥梁模式的时候指出,桥梁模式的用意是"将抽象化(Abstraction)与实现化(Implementation)脱耦,使得二者可以独立地变化".这句话有三个关键词,也就是抽象化.实现化和脱耦. 桥梁模式的成员 抽象化 存在于多个实体中

java设计模式之桥梁模式(Bridge)

1.桥梁模式 与 策略模式 非常相似 (其实很多设计模式都相似,因为所有的模式都是按照设计原则 而设计出来的,设计原则就相当于武功的心法,设计模式就是招式,只要心法过硬,就可以无招胜有招了.) 这里也有比较详细的说明 策略模式 VS 桥梁模式 (画画,使用蜡笔和使用毛笔以及颜料的区别) 好了,这里先说 桥梁模式,最后再总结两者的区别 2.桥梁模式(还是那样,设计模式就是为了代码健壮,代码重用,所以高内聚,低耦合永远都是那么受欢迎,什么抽象类啊,接口啊···) 场景,农民施肥. 这里农民类 调用

桥梁模式(Bridge)

桥梁模式属于结构类的设计模式,示意结构图如下: 桥梁模式所涉及的角色有: ● 抽象化(Abstraction)角色:抽象化给出的定义,并保存一个对实现化对象的引用. ● 修正抽象化(RefinedAbstraction)角色:扩展抽象化角色,改变和修正父类对抽象化的定义. ● 实现化(Implementor)角色:这个角色给出实现化角色的接口,但不给出具体的实现.必须指出的是,这个接口不一定和抽象化角色的接口定义相同,实际上,这两个接口可以非常不一样.实现化角色应当只给出底层操作,而抽象化角色应

php桥接模式(bridge pattern)

有点通了 <?php /* The bridge pattern is used when we want to decouple a class or abstraction from its implementation, allowing them both to change independently. This is useful when the class and its implementation vary often */ interface MessagingInterf

设计模式-08桥接模式(Bridge Pattern)

1.模式动机 设想如果要绘制矩形.圆形.椭圆.正方形,我们至少需要4个形状类,但是如果绘制的图形需要具有不同的颜色,如红色.绿色.蓝色等,此时至少有如下两种设计方案: 第一种设计方案是为每一种形状都提供一套各种颜色的版本. 第二种设计方案是根据实际需要对形状和颜色进行组合 对于有两个变化维度(即两个变化的原因)的系统,采用方案二来进行设计系统中类的个数更少,且系统扩展更为方便.设计方案二即是桥接模式的应用.桥接模式将继承关系转换为关联关系,从而降低了类与类之间的耦合,减少了代码编写量. 当然,这