SoFunction
Updated on 2025-04-03

Detailed explanation of how to use the intermediary mode in JS design pattern

Mediator Pattern

definition:

It is a behavioral design pattern used to reduce coupling between multiple objects.

effect:

The mediator pattern centrally manages and controls the interaction between objects by introducing a mediator object.

Features:

In the intermediary mode, multiple objects do not communicate directly with each other, but communicate through the intermediary. The mediator object encapsulates the interactive logic between objects. Each object only needs to communicate with the mediator, but does not need to understand the existence of other objects.

Participants:

  • Abstract Mediator: Defines the interface of the mediator object and declares the communication method between objects.
  • Concrete Mediator: implements the interface of abstract mediators, responsible for coordinating and controlling communications between various objects.
  • Abstract Colleague: Each colleague class knows its mediator object and communicates with other colleague classes through the mediator object.
  • Concrete College: It implements the interface of the colleague class, is responsible for handling its own behavior, and communicates with other colleague classes through intermediaries.

Workflow:

  • definitionAbstract intermediaryInterface, where communication methods between objects are declared.
  • definitionSpecific intermediary category, realizes the abstract mediator interface and is responsible for coordinating and controlling communications between various objects.
  • definitionAbstract colleague class interface, which declares methods of communicating with intermediaries.
  • definitionSpecific colleagues, implement colleague-like interfaces and implement your own behavior logic.
  • In specific colleagues,References to the object holding the intermediary, communicate with other colleagues through intermediaries.

Advantages:

  • Reduces coupling between objects, making interactions between objects more flexible and scalable.
  • Centrally manage and control the interactive logic between objects, reducing the complexity of the code.

Disadvantages:

  • Intermediary object may becomecomplex, because it handles the interactive logic between multiple objects.
  • Introducing mediator objects may lead toIncrease in quantity。

For example:

Suppose we have a simple chat room application with multiple user objects and a mediator object to coordinate communication between users. Each user object can send messages to other users and receive messages sent by other users.

First, define the abstract mediator interface:

abstract class AbstractMediator {
  // Abstract method for communication  abstract sendMessage(sender: Colleague, message: string): void;
}

Then, define the specific intermediary class:

class ChatRoomMediator extends AbstractMediator {
  users = [];
  // The intermediary collects colleague-class instance objects  addUser(user: Colleague) {
    (user);
  }
  // Abstract method for implementing communication  sendMessage(sender: Colleague, message: string) {
    for (let user of ) {
      user !== sender && (sender, message);
    }
  }
}

Next, define the abstract colleague class interface:

abstract class Colleague {
  constructor(public mediator: AbstractMediator) {}
  // As participants in the intermediary model, each colleague-like object has a method of sending and processing information  // The difference is that the method of sending information has been implemented by abstract classes, and the method of processing information needs to be customized according to the subclass situation  send(message) {
    (this, message);
  }
  abstract receiveMessage(sender: Colleague, message: string): void;
}

Then, define the specific colleague class:

class User extends Colleague {
  constructor(public name: string, mediator: AbstractMediator) {super(mediator)}
  receiveMessage(sender: Colleague, message: string) {
    (`${} received a message from ${}: ${message}`);
  }
}

Finally, create mediator objects and colleague objects in the client code; use mediator objects to collect colleague objects participating in the conversation and communicate with examples:

// Create an intermediary objectconst chatRoomMediator = new ChatRoomMediator();
// Create a colleague object// Every colleague class object should keep a reference to the intermediary objectconst user1 = new User('User 1', chatRoomMediator);
const user2 = new User('User 2', chatRoomMediator);
const user3 = new User('User 3', chatRoomMediator);
// Mediator object collects colleague class objects; in fact, it can also be made into a new User. When the instance is automatically added to the mediator users array, and the constructor of the specific colleague class is modified to:/*
  constructor(name: string, mediator: AbstractMediator) {
    super(mediator);
     = name;
    (this);
  }
*/
(user1);
(user2);
(user3);
// Example of communication between users through intermediaries('Hello, everyone!');
('Hi, User 1!');
('Nice to meet you all!');
/*
>>>
User 2 received a message from User 1: Hello, everyone!
User 3 received a message from User 1: Hello, everyone!
User 1 received a message from User 2: Hi, User 1!
User 3 received a message from User 2: Hi, User 1!
User 1 received a message from User 3: Nice to meet you all!
User 2 received a message from User 3: Nice to meet you all!
*/

Other application scenarios:

WS client and server

  • The client and server of WebSocket (ws) can be regarded as the colleague class (Colleague) and the Concrete Mediator class (Concrete Mediator) in the mediator pattern.
  • In WebSocket communication, two-way communication between the client and the server is carried out through the WebSocket protocol.
  • Both the client and the server need to connect to the same WebSocket server and communicate by sending and receiving messages. In this case, the WebSocket server can act as a mediator object, responsible for coordinating and controlling communications between the client and the server.
  • The client and the server can define corresponding sending and receiving methods and communicate through the intermediary (WebSocket server).
  • The client can send messages to the server through the send method of the WebSocket object, and the server can listen to and process messages sent by the client through the onmessage event of the WebSocket object.

Here is a simple example code that demonstrates communication between WebSocket client and server:

Client code:

const socket = new WebSocket('ws://localhost:8080');
 = () => {
  ('WebSocket connection opened.');
  ('Hello, server!');
};
 = (event) => {
  const message = ;
  ('Received message from server:', message);
};
 = () => {
  ('WebSocket connection closed.');
};

Server code:

const WebSocket = require('ws');
const wss = new ({ port: 8080 });
('connection', (ws) => {
  ('WebSocket connection established.');
  ('message', (message) => {
    ('Received message from client:', message);
    ('Hello, client!');
  });
  ('close', () => {
    ('WebSocket connection closed.');
  });
});

Electron's main process and rendering process

  • In Electron, the main process and the Renderer Process can be regarded as the mediator and the colleague class in the mediator pattern.
  • They communicate through IPC (Inter-Process Communication).
  • The main process is the core of the Electron application and is responsible for managing the application's life cycle, window management, and interaction with system resources.
  • The rendering process is a web page created by the main process. Each rendering process runs in an independent sandbox environment and is responsible for displaying and interacting with the user interface.
  • The main process can listen to and process messages from the rendering process through the ipcMain object, and the rendering process can send messages to the main process through the ipcRenderer object.

Here is a simple example code that demonstrates the communication between the Electron main process and the rendering process:

Main process code:

const { app, BrowserWindow, ipcMain } = require('electron');
let mainWindow;
('ready', () => {
  mainWindow = new BrowserWindow();
  ('');
});
('messageFromRenderer', (event, message) => {
  ('Received message from renderer:', message);
  ('messageToRenderer', 'Hello, renderer!');
});

Rendering process code():

<!DOCTYPE html>
<html>
  <body>
    <script>
      const { ipcRenderer } = require('electron');
      ('messageFromRenderer', 'Hello, main process!');
      ('messageToRenderer', (event, message) => {
        ('Received message from main process:', message);
      });
    </script>
  </body>
</html>

The relationship between computer motherboard hardware

  • In computer hardware, components and buses on the motherboard can be regarded as colleagues and Concrete Mediators in the mediator pattern.
  • Data transmission and coordination are required between various components on the motherboard (such as processors, memory, graphics cards, etc.).
  • These elements communicate through a bus, which acts as an intermediary and is responsible for coordinating and controlling communications between elements.
  • The bus acts as an intermediary object and centrally manages and controls communication between various components. The components do not communicate directly with each other, but transmit and interact data through the bus.
  • Each element knows the existence of the bus and sends and receives data through the bus.

As shown in the figure below:

+---------------------+
|      Mainboard      |
+---------------------+
|       Processor     |
|        Memory       |
|        GPU          |
|        ...          |
+---------------------+
         |
         |   +---------+
         +---|  Bus    |
             +---------+

Business usage scenarios:

  • Event Centralization: The mediator pattern can be used to centrally manage event processing of multiple objects. A mediator object can act as an event center, receive events from multiple objects, and broadcast or forward as needed.
class Mediator {
  constructor() {
     = [];
  }
  subscribe(subscriber) {
    (subscriber);
  }
  unsubscribe(subscriber) {
     = ((s) => s !== subscriber);
  }
  broadcast(event, data) {
    for (let subscriber of ) {
      (event, data);
    }
  }
}
class Subscriber {
  handleEvent(event, data) {
    (`Received event '${event}' with data:`, data);
  }
}
const mediator = new Mediator();
const subscriber1 = new Subscriber();
(subscriber1);
const subscriber2 = new Subscriber();
(subscriber2);
('click', { x: 100, y: 200 });
  • Form Validation: Mediator pattern can be used to jointly verify multiple fields in a form. Each field can register its own verification rules and error handling functions through the mediator object, which is responsible for coordinating and triggering the verification logic.
class Mediator {
  constructor() {
     = {};
  }
  registerField(field, validationRules, errorHandle) {
    [field] = { validationRules, errorHandle };
  }
  validate() {
    let isValid = true;
    for (let field in ) {
      const { validationRules, errorHandle } = [field];
      const value = (field).value;
      for (let rule of validationRules) {
        if (!(value)) {
          errorHandle(field);
          isValid = false;
          break;
        }
      }
    }
    return isValid;
  }
}
const mediator = new Mediator();
(
  'username',
  [/.{5,}/],
  (field) => (`Invalid value for field '${field}'.`)
);
(
  'password',
  [/.{8,}/, /[A-Z]/, /[0-9]/],
  (field) => (`Invalid value for field '${field}'.`)
);
('submit-button').addEventListener('click', () => {
  if (()) {
    ('Form submitted successfully.');
  }
});

Summarize:

The intermediary model provides a scalable and maintainable way to handle complex interactions, suitable for:

  • There are complex interactions between multiple objects in the system, resulting in high coupling.
  • The interactive logic between objects needs to be centrally managed and controlled to avoid being scattered among multiple objects.

The above is the detailed explanation of the usage method of the intermediary model of JS design pattern. For more information about the JS intermediary model, please pay attention to my other related articles!