Write a publish-subscribe model with JS

What is the publish-subscribe model? Can you write it by hand? Is it different from the observer pattern? ...

1. Scene introduction

Let's look at a scenario like this:

Suppose there is a social platform with a famous person named Nami

Nami is very talented and versatile. She currently has two skills: writing songs and shooting videos.

She will post these works on the platform. Fans who follow her will receive these contents

Now he has 3 fans, namely: Luffy, Zoro, Sanji

Every time Nami releases a work, the messages received on the accounts of the three fans will be updated.

Now let’s express it in code:

const luffy = {
  update: function (songs, videos) {
    console.log(songs, videos);
  },
};
const zoro = {
  update: function (songs, videos) {
    console.log(songs, videos);
  },
};
const sanji = {
  update: function (songs, videos) {
    console.log(songs, videos);
  },
};

const nami = {
  // This method will be called whenever Nami's work is updated workUpdate: function () {
    // Get the works const songs = this.getSongs();
    const videos = this.getVideos();

    //Account update luffy.update(songs, videos);
    zoro.update(songs, videos);
    sanji.update(songs, videos);
  },
  getSongs: function () {
    return "mp3";
  },
  getVideos: function () {
    return "mp4";
  },
};

Now comes the problem

• If Nami gains another fan Robin , I need to add a robin object and modify workUpdate method.
• If Nami has a new skill: writing novels, I need to modify both workUpdate function and the update method in each fan object, because the parameter has been increased by one.
  

Found any problem?

The coupling between the fan object and the influencer object is too high, making it difficult for each to scale independently.

2 Code Optimization

2.1 Solve the problem of increasing fans

Let’s solve the first problem first so that we don’t need to modify workUpdate method when adding fans.

First, we abstract the "big V" into a class Star, use the array fans to save the fan list, and add a method addFans to add fans.

class Star {
  constructor() {
    this.fans = [];
  }
  addFans(fan) {
    this.fans.push(fan)
  }
  workUpdate() {
    const songs = this.getSongs();
    const videos = this.getVideos();
    this.fans.forEach((item) => item.update(songs, videos));
  }
  getSongs() {
    return "MP3";
  }
  getVideos() {
    return "MP4";
  }
}

Next, we abstract "fans" into a class Fan. When creating a fan object, we pass in the "big V" object and call the addFans method of the big V to add it to the fan list.

class Fan {
  constructor(name, star) {
    this.name = name
    this.star = star
    this.star.addFans(this)
  }
  update(songs, videos) {
    console.log(songs, videos);
  }
}

Now we don't have to change the code to add fans

const nami = new Star()
const luffy = new Fan("luffy", nami);
const zoro = new Fan("zoro", nami);
const sanji = new Fan("sanji", nami);
const robin = new Fan("robin", nami);
nami.workUpdate()

2.2 Solve the problem of adding works

We add a works array to save the works of big V, and add get and set methods to it.

class Star {
  constructor() {
    this.fans = [];
    this.works = [];
  }
  addFans(fan) {
    this.fans.push(fan);
  }
  setWorks(work) {
    this.works.push(work);
    // After adding the work, call the update method this.workUpdate();
  }
  getWorks() {
    return this.works;
  }
  workUpdate() {
    this.fans.forEach((item) => item.update());
  }
}

Modify the Fan class accordingly:

class Fan {
  constructor(name, star) {
    this.name = name
    this.star = star
    this.star.addFans(this)
  }
  update() {
    console.log(`${this.name}:${this.star.getWorks()}`)
  }
}

Now big Vs don’t need to change the code to add works:

const nami = new Star();
nami.setWorks('song')
nami.setWorks('video')
nami.setWorks('novel')
const luffy = new Fan("luffy", nami);
const zoro = new Fan("zoro", nami);
const sanji = new Fan("sanji", nami);
nami.workUpdate();

3 Observer Pattern

As you can see, in the above example, there is a one-to-many dependency relationship between a nami object and multiple fan objects. When the nami object has a work update, all fan objects following her will receive a notification.

In fact, this is the observer mode

Observer pattern: defines a one-to-many dependency relationship between objects. When the state of an object changes, all objects that depend on it are notified and automatically updated.

We further abstract the code in 2.2:

The “fans” are regarded as Observer , and the “big V” is regarded as the object of observation, called Subject .

Subject maintains an observer list observerList (originally fans array). When the state of Subject changes (original workUpdate), all observers are notified by calling the notify (original workUpdate ) method and their update methods are executed.

The specific code is as follows:

//Observer: Subject class Subject {
  constructor() {
    this.observerList = [];
    // Represents the subject state this.state = 0;
  }
  addObserver(observer) {
    this.observerList.push(observer);
  }
  // Change the theme state setState(state) {
    this.state = state;
    //After the state changes, notify all observers this.notify();
  }
  getState() {
    return this.state;
  }
  notify() {
    this.observerList.forEach((observer) => observer.update());
  }
}

//Observer class Observer {
  constructor(name, subject) {
    this.name = name;
    this.subject = subject;
    this.subject.addObserver(this);
  }
  update() {
    console.log(`${this.name}:${this.subject.state}`);
  }
}

4 Agents appear

Since big Vs are busy with their business, they need agents to maintain the connection between artists and fans.

A broker’s duties include:

• To maintain the fans of the big V, the agent will have a fan list
• The new works of the big V will be handed over to the agent, and the agent will be responsible for sending the new works to the fans in the fan list.
  

Abstract into a class as follows:

class Manager {
  constructor() {
    this.fans = [];
    this.works = [];
  }
  addFans(fan) {
    this.fans.push(fan);
  }
  setWorks(work) {
    this.works.push(work);
    // After adding the work, call the update method this.workUpdate();
  }
  getWorks() {
    return this.works;
  }
  workUpdate() {
    this.fans.forEach((item) => item.update());
  }
}

Um? Where have you seen this code before?

Yes, it is exactly the same as the Star class in 2.2, except that the class name has been changed.

So does it make sense to do this?

In fact, the code is exactly the same because in the Star class of 2.2 we only wrote functions related to publishing (i.e. publishing works) and subscribing (i.e. maintaining a list of fans); and the Star class itself may have more than just this work, such as creating content.

Now we extract the publishing and subscription work from Star class and give it to Manager to be fully responsible. Star class only needs to hand over the work to Manager after the creation is completed.

On the other hand, Fan no longer interact directly with Star . They only care about whether they can receive the works, so they interact directly with Manager . Fan subscribe to the Manager (this behavior is equivalent to adding fans to the fan list maintained by Manager ) and get the desired works from Manager .

So the code for Star and Fan is as follows:

class Star {
  constructor() {}
  // Create create(manager) {
    // Submit the created new work to the agent manager.setWorks("new work");
  }
}

class Fan {
  constructor(name, manager) {
    this.name = name;
    this.manager = manager;
    this.manager.addFans(this);
  }
  update() {
    console.log(`${this.name}:${this.manager.getWorks()}`);
  }
}

5 Publish-Subscribe Model

Earlier, we used a broker to be responsible for publishing and subscribing, and did not allow Star and Fan to interact directly, thus achieving the effect of decoupling the two.

This is the publish-subscribe model

We further abstract the Manager in 4:

Think of "fans" as Subscriber ; think of "big Vs" as publishers of content, called Publisher in the publish-subscribe model; think of "brokers" as publish-subscribe centers (or middlemen, Broker )

The specific code is as follows:

//Publish and subscribe scheduling center class Broker {
  constructor() {
    this.subscribers = [];
    // Represents the subject state this.state = 0;
  }
  // Subscribesubscribe(subscriber) {
    this.subscribers.push(subscriber);
  }
  // Change the theme state setState(state) {
    this.state = state;
    //After the state changes, publish this.publish();
  }
  getState() {
    return this.state;
  }
  // Publish publish() {
    this.subscribers.forEach((subscriber) => subscriber.update());
  }
}

// Publisher class Publisher {
  constructor() {}
  changeState(broker, state) {
    broker.setState(state);
  }
}

class Subscriber {
  constructor(name, broker) {
    this.name = name;
    this.broker = broker;
    this.broker.subscribe(this);
  }
  update() {
    console.log(`${this.name}:${this.broker.getState()}`);
  }
}

Let's run it and see the effect:

// Create a dispatch center const broker = new Broker()
// Create a publisher const publisher = new Publisher()
// Create a subscriber const subscribe1 = new Subscriber('s1', broker)
const subscribe2 = new Subscriber('s2', broker)
const subscribe3 = new Subscriber('s3', broker)
// The publisher changes the state and notifies the dispatch center, which then notifies each subscriber publisher.changeState(broker, 1)

6 Comparison between Observer Mode and Publish-Subscribe Mode

In terms of the number of roles

• The observer pattern has only two roles: observer and observed
• The publish-subscribe model has three roles: publisher, subscriber, and middleman (publish-subscribe center)
  

From the coupling degree

• The observer mode is in a loosely coupled state, that is, the two still interact, but it is easy to expand each other without affecting each other.
• In the publish-subscribe model, there is no coupling between publishers and subscribers, achieving the effect of decoupling between objects.
  

From the perspective of intention

• Both: implement a one-to-many dependency relationship between objects. When the state of an object changes, all objects that depend on it will be notified and automatically updated.

This is the end of this article about writing a publish-subscribe model with JS. For more relevant content about writing a publish-subscribe model with JS, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!