前端必须掌握的设计模式——发布订阅模式

目录

定义

对比观察者模式

观察者模式

发布订阅模式

举例说明

代码实现

总结

定义

        发布订阅模式（Publish-Subscribe Pattern）属于 行为型 设计模式，与观察者模式类似，但在消息通知的链路上是不一样的。简而言之，发布订阅模式可以看作是观察者模式的优化版本。

对比观察者模式

观察者模式

• 被观察者直接发消息给观察者，当消息事件触发时，被观察者直接通知所有列表中的观察者。
• 被观察者耦合了一个观察者列表。
• 异步支持不够，当触发消息事件时，被观察者直接通知观察者。
• 安全性存在一定问题，观察者通常会对被观察者监听，可能得到被观察者内部的状态。

发布订阅模式

• 不再直接通信，发布者和订阅者中间存在一个第三方中介，发布者和订阅者都与这个第三方通信。
• 发布者不再维护观察者列表，甚至发布者和订阅者彼此并不知道对方的存在关系。
• 异步可支持，当触发消息事件时，第三方中介可以进行延迟发送。
• 安全性较好，发布者和订阅者解耦，需要通过第三方中介通信，获取发布者内部状态也必须通过特意暴露的方法才能访问。

        总体而言，发布订阅模式更适合一些大型的、复杂的、有异步要求、安全性要求高的场景，如：消息队列（RabbitMQ）、流处理（Kafka）。观察者模式相对实现更简单，适合一些轻量级、无特别要求的场景，如一些GUI工具。

举例说明

        上回书说到，蚁人、绿巨人、超人去商店购买能量饮料但缺货，商店老板一套观察者模式完美解决了供需问题。但随着商店生意日益兴旺，能量饮料也越卖越好，也常常供不应求。在这种环境下，商店老板要维护的客户也越来越多，无疑提升了商店的运营成本。

        上回书传送门：【前端必须掌握的设计模式——观察者模式】

        商店老板未雨绸缪，找到了一家第三方购物平台，将能量饮料等商品提交，客户可以在中间平台下单，平台再向商店下单，这样商店只需跟中间平台交互即可。

        上述的情况，其实观察者模式也能够较轻松解决，当然只是在单场景下，如果商品数量较多时，商店可能就忙不过来了。同时，能量饮料随着销量的增长又推出了新品-紫色的葡萄口味，这时商店老板将新品也上传至中间平台。

• 蚁人：我喜欢葡萄口味的，我不要旧的了，我只要新的。
• 绿巨人：吼～小孩子才做选择，我全都要。
• 超人：葡萄口味有什么好喝的，经典款才是yyds。

        就这样蚁人放弃了经典款，只订阅了新品，绿巨人都订阅了，超人仍然保持着原来的样子。当有一天，商店到了一批经典款只需要告知中间平台即可，中间平台根据订阅列表可以查到只有绿巨人和超人订阅了，通知他们两个吧；第二天到了一批新品，中间平台查到只有蚁人和绿巨人订阅了，通知他们两个吧！按照这种模式继续进行下去，哪怕出上百件商品，也能够井井有条，商店压力也不会太大。

代码实现

        根据以上场景绘制出UML，分别设计了一个发布者接口（IPublisher）、订阅者接口（ISubscriber）以及中间平台接口（IBroker），要实现的发布者只需要发布消息（publish），订阅者需要有订阅行为（subscribe）和接收消息的行为（receive），中间平台需要处理发布（publish）和订阅逻辑（subscribe）起到一个“中介”的作用。

        代码实现中，中间平台类的数据结构设计成了Map形式，以key-value映射方式进行管理，其中key代表类型（经典款、新品），value代表订阅者（蚁人、绿巨人、超人等等）。 

// 发布者接口
interface IPublisher {
	publish: (topic: string, message: any) => void;
}

// 订阅者接口
interface ISubscriber {
	subscribe: (topic: string) => void;
	receive: (message: string) => void;
}

// 中间平台接口
interface IBroker {
	subscribe: (topic: string, subscriber: ISubscriber) => void;
	publish: (topic: string, message: any) => void;
}

// 中间平台类 帮发布者发布消息 帮订阅者订阅消息
class Broker implements IBroker {
	private topics: Map<string, ISubscriber[]> = new Map();

	subscribe(topic: string, subscriber: ISubscriber): void {
		let subTopicSubscribers = this.topics.get(topic) || [];
		subTopicSubscribers.push(subscriber);
		this.topics.set(topic, subTopicSubscribers);
	}

	publish(topic: string, message: string): void {
		const subTopicSubscribers = this.topics.get(topic) || [];
		for (const subscriber of subTopicSubscribers) {
			subscriber.receive(message);
		}
	}
}

// 发布者
class Publisher implements IPublisher {
	private broker: IBroker;

	constructor(broker: IBroker) {
		this.broker = broker;
	}

	publish(topic: string, message: string): void {
		console.log(`商店发布了一个${topic}的消息:${message}`);
		this.broker.publish(topic, message);
	}
}

// 订阅者
class Subscriber implements ISubscriber {
	private name: string;
	private broker: IBroker;

	constructor(name: string, broker: IBroker) {
		this.name = name;
		this.broker = broker;
	}

	subscribe(topic: string) {
		this.broker.subscribe(topic, this);
	}

	receive(message: string) {
		console.log(`${this.name}接收到消息:${message}`);
	}
}

// 客户端
const broker = new Broker(); // 中间平台实例
const store = new Publisher(broker); // 发布者实例
const antman = new Subscriber('蚁人', broker); // 订阅者实例
const hulk = new Subscriber('绿巨人', broker); // 订阅者实例
const superman = new Subscriber('超人', broker); // 订阅者实例

// 蚁人只关注新品
antman.subscribe('能量饮料-新品');
// 绿巨人关注经典款和新品
hulk.subscribe('能量饮料-经典款');
hulk.subscribe('能量饮料-新品');
// 超人只关注经典款
superman.subscribe('能量饮料-经典款');

store.publish('能量饮料-经典款', '经典款到货啦！');
store.publish('能量饮料-新品', '新品到货啦！');

        在客户端我们需要分别创建发布者实例、中间平台实例以及各个订阅者的实例，其中创建发布者实例时将中间平台实例当作参数传入， 目的是为了确保发布者将消息发给的对象绑定为中间平台的实例；在创建订阅者实例时将中间瓶体啊实例当作参数传入，目的是为了确保订阅者订阅消息的目标绑定为中间平台。这样一来，中间平台要做的就是帮发布者发布，帮订阅者订阅。

        当商店发布了“能量饮料-经典款”调用了publish方法，publish方法内部会调用中间平台的publish方法，将消息转发，中间平台会在维护的订阅者列表中查找符合条件的订阅者，调用他们内部的receive方法接收消息。

        根据输出结果，我们可以准确得到输出的结果。绿巨人全都订阅了，所以商店无论是发布经典款还是新品的消息，绿巨人都会收到；超人和蚁人只能收到自己订阅的商品信息，未订阅的不会影响他们。

总结

        发布订阅模式作为观察者模式的改良版，适合较为复杂的应用场景，前端最经典的应用就是Vue的数据双向绑定，Vue数据双向绑定的代码也会更加符合代码设计的艺术。前端必须掌握的设计模式系列持续更新，如果对您有帮助希望多多点赞哦！