使用桥接模式设计复杂的消息系统

简介: 举个例子,我们在平时办公的时候经常通过邮件消息、短信消息或者系统内消息与同事进行沟通。尤其在走一些审批流程的时候,我们需要记录这些过程以备查。根据类型来划分,消息可以分为邮件消息、短信消息和系统内消息。但是,根据紧急程度来划分,消息可以分为普通消息、加急消息和特急消息。显然,整个消息系统可以划分为两个维度,如下图所示。

本文节选自《设计模式就该这样学》


举个例子,我们在平时办公的时候经常通过邮件消息、短信消息或者系统内消息与同事进行沟通。尤其在走一些审批流程的时候,我们需要记录这些过程以备查。根据类型来划分,消息可以分为邮件消息、短信消息和系统内消息。但是,根据紧急程度来划分,消息可以分为普通消息、加急消息和特急消息。显然,整个消息系统可以划分为两个维度,如下图所示。

20211108160648183.png

如果我们用继承,则情况就复杂了,而且也不利于扩展。邮件消息可以是普通的,也可以是加急的;短信消息可以是普通的,也可以是加急的。下面我们用桥接模式来解决这个问题。

首先创建一个IMessage接口担任桥接的角色。

/**
 * 实现消息发送的统一接口
 */
public interface IMessage {
    //要发送的消息的内容和接收人
    void send(String message, String toUser);
}

创建邮件消息实现EmailMessage类。

/**
 * 邮件消息的实现类
 */
public class EmailMessage implements IMessage {
    public void send(String message, String toUser) {
        System.out.println("使用邮件消息发送" + message + "给" + toUser);
    }
}

创建短信消息实现SmsMessage类。

/**
 * 短信消息的实现类
 * SMS(Short IMessage Service)短信消息服务
 */
public class SmsMessage implements IMessage {
    public void send(String message, String toUser) {
        System.out.println("使用短信消息发送" + message + "给" + toUser);
    }
}

然后创建桥接抽象角色AbstractMessage类。

/**
 * 抽象消息类
 */
public abstract class AbstractMessage {
    //持有一个实现部分的对象
    IMessage message;
    //构造方法,传入实现部分的对象
    public AbstractMessage(IMessage message) {
        this.message = message;
    }
    //发送消息,委派给实现部分的方法
    public void sendMessage(String message, String toUser) {
        this.message.send(message, toUser);
    }
}

创建具体实现普通消息NomalMessage类。

/**
 * 普通消息类
 */
public class NomalMessage extends AbstractMessage {
    //构造方法,传入实现部分的对象
    public NomalMessage(IMessage message) {
        super(message);
    }
    @Override
    public void sendMessage(String message, String toUser) {
        //对于普通消息,直接调用父类方法发送消息即可
        super.sendMessage(message, toUser);
    }
}

创建具体实现加急消息UrgencyMessage类。

/**
 * 加急消息类
 */
public class UrgencyMessage extends AbstractMessage {
    //构造方法
    public UrgencyMessage(IMessage message) {
        super(message);
    }
    @Override
    public void sendMessage(String message, String toUser) {
        message = "加急:" + message;
        super.sendMessage(message, toUser);
    }
    //扩展它功能,监控某个消息的处理状态
    public Object watch(String messageId) {
        //根据给出的消息编码(messageId)查询消息的处理状态
        //组织成监控的处理状态,然后返回
        return null;
    }
}

最后编写客户端测试代码。

 public static void main(String[] args) {
        IMessage message = new SmsMessage();
        AbstractMessage abstractMessage = new NomalMessage(message);
        abstractMessage.sendMessage("加班申请速批", "王总");
        message = new EmailMessage();
        abstractMessage = new UrgencyMessage(message);
        abstractMessage.sendMessage("加班申请速批", "王总");
}

运行结果如下图所示。

20211108160648374.png

在上面的案例中,我们采用桥接模式解耦了“消息类型”和“消息紧急程度”这两个独立变化的维度。后续如果有更多的消息类型,比如微信、钉钉等,则直接新建一个类继承IMessage即可;如果紧急程度需要新增,则同样只需新建一个类实现AbstractMessage类即可。


【推荐】Tom弹架构:30个设计模式真实案例(附源码),挑战年薪60W不是梦


本文为“Tom弹架构”原创,转载请注明出处。技术在于分享,我分享我快乐!

如果本文对您有帮助,欢迎关注和点赞;如果您有任何建议也可留言评论或私信,您的支持是我坚持创作的动力。

相关文章
|
6月前
|
设计模式 开发框架 监控
精准解读桥接模式-用桥接模式构建可扩展的软件系统
桥接模式是一种设计模式,旨在将抽象和实现部分分离,使它们可以独立地变化。这种模式的目的是提高系统的灵活性和可扩展性。桥接模式的主要思想是将抽象和实现通过一个桥接类连接起来,从而实现它们的解耦。在这种模式中,抽象部分可以根据需要进行扩展,而实现部分可以自由地变化,而不影响彼此。桥接模式在处理多个独立变化的维度、解耦继承关系、处理平台差异和扩展现有系统等方面具有广泛的应用领域。通过使用桥接模式,可以提高系统的可维护性和可扩展性,使系统更加灵活和适应变化。通过桥接模式,将系统中的抽象部分与实现部分解耦,从而...
166 0
精准解读桥接模式-用桥接模式构建可扩展的软件系统
|
15天前
|
设计模式 网络协议 Java
10.桥接模式设计思想
本文介绍了桥接模式的设计思想和实现方法。桥接模式通过将抽象部分与实现部分分离,使它们可以独立变化,解决了多层继承带来的复杂性和耦合性问题。文章详细讲解了桥接模式的由来、定义、应用场景和实现步骤,并通过具体实例演示了如何在支付场景中使用桥接模式。此外,还讨论了桥接模式的优缺点及其适用环境,提供了丰富的代码示例和进一步学习的资源链接。
62 2
|
4月前
|
设计模式 消息中间件 负载均衡
实现可扩展和可靠的分布式系统的Java设计模式
实现可扩展和可靠的分布式系统的Java设计模式
|
4月前
|
设计模式 算法
交易链路设计原则&模式问题之中介者(Mediator)方法设计模式是什么,如何解决
交易链路设计原则&模式问题之中介者(Mediator)方法设计模式是什么,如何解决
|
5月前
|
设计模式
桥接模式-大话设计模式
桥接模式-大话设计模式
|
5月前
|
设计模式
外观模式-大话设计模式
外观模式-大话设计模式
|
6月前
|
消息中间件 缓存 监控
【C++ 观察者模式的应用】跨进程观察者模式实战:结合ZeroMQ和传统方法
【C++ 观察者模式的应用】跨进程观察者模式实战:结合ZeroMQ和传统方法
252 1
|
6月前
|
设计模式 程序员 数据处理
C++ 职责链模式:轻松实现解耦和扩展性
C++ 职责链模式:轻松实现解耦和扩展性
83 1
|
6月前
|
设计模式 存储 API
C++桥接模式大解析:轻松设计与实现高效软件架构
C++桥接模式大解析:轻松设计与实现高效软件架构
286 0
|
设计模式
设计模式——单一职责模式之桥模式
在软件组件的设计中,如果责任划分的不清晰,使用继承得到的结果往往是随着需求的变化,子类急剧膨胀,同时充斥着重复代码,这时候的关键是划清责任。
90 0