Mediator Pattern_JavaScript Design Patterns 5

I. Mediator Pattern

A mediator, also known as a third party. Originally, two parties interact directly. After introducing a mediator, all interactions must be completed through the third party.

For example, originally communication was through walkie-talkies directly. Now it's changed to email, with the mail server responsible for forwarding. Corresponding to module interaction, the original mesh structure now becomes a star structure. Dependencies between modules are reduced, uniformly depending on the central point (mediator). At the same time, the central point thus gains more control permissions, such as mass mailing, bubble notifications, etc.

All interactions between modules must go through the mediator. Modules are not familiar with each other. Just publish the message to the mediator, and the mediator will naturally notify those who need to know (subscribed to the corresponding topic). The system operates with such a mechanism. The mediator is the control core.

II. Specific Implementation of Mediator Pattern

1. Simplest Mediator Pattern

var mediator = (function() {
    var topics = {},
        subUid = -1;

    var publish = function(topic, args) {
        if (!topics[topic]) {
            return false;
        }

        var subscribers = topics[topic],
            len = subscribers ? subscribers.length : 0;
        while (len--) {
            subscribers[len].func(topic, args);
        }

        return true;
    };

    var subscribe = function(topic, func) {
        if (!topics[topic]) {
            topics[topic] = [];
        }

        var token = (++subUid).toString();
        topics[topic].push({
            token: token,
            func: func
        });

        return token;
    };

    return {
        publish: publish,
        subscribe: subscribe,
        // Indeed, there's no more suitable name than installTo
        installTo: function(obj) {
            obj.publish = publish;
            obj.subscribe = subscribe;
        }
    }
}());


// Specific application
var mod1 = {
    run: function(arg) {
        console.log('mod1 received ' + arg);
    }
};
var mod2 = {};
var topic = 'myTopic';
mediator.installTo(mod1);
mediator.installTo(mod2);
// mod1 subscribes to message
mod1.subscribe(topic, function(t, arg) {
    mod1.run(arg);
});
// mod2 publishes message
mod2.publish(topic, 'data');

At first glance, there's no difference from the [Publish/Subscribe Pattern] introduced earlier. One difference reflected in the example is that any module can publish messages, while in the Publish/Subscribe Pattern, observers can only passively receive messages. Specific differences are explained in detail below.

2. Powerful Mediator Pattern

http://thejacklawson.com/Mediator.js/index.html provides a powerful implementation, supporting topic namespaces, message bubbling, priority, etc.

Source code (with comments) see http://thejacklawson.com/Mediator.js/mediator.html, or github

III. Mediator Pattern vs Publish/Subscribe Pattern

(Of course, the Publish/Subscribe Pattern originates from the Observer Pattern. The Mediator Pattern is considered a grandchild generation.)

From an implementation perspective, the Mediator Pattern and Publish/Subscribe Pattern are very similar. Even if you look carefully, you might not discover the differences. Main differences are as follows:

1. Communication Method

In the Mediator Pattern, every module can publish messages (the mediator itself can also publish messages). In the Publish/Subscribe Pattern, observers can only passively wait for messages.

2. Module Dependency Structure

The Mediator Pattern is a star structure. The mediator is a "control point". In the Publish/Subscribe Pattern, the publish-subscribe mechanism itself is a "control layer", meaning high-level can operate lower-level modules through the control layer (although high-level can also control lower-level modules through the mediator, this is not the original intention of the star structure).

3. Information Publishing Method

Changed from many-to-many to many-to-one. All modules can only directly communicate with the mediator.

Disadvantages:

1. Single Point of Failure

This is the biggest disadvantage of the Mediator Pattern. The Publish/Subscribe Pattern also has this disadvantage, but the Mediator Pattern expresses it more sharply (combine understanding of "control point" and "control layer").

2. Performance Degradation

Modules must interact through a third party. Compared to direct interaction, there's definitely performance degradation. This is a common side effect of design patterns.

3. Increased Difficulty in Logic Implementation

Loose coupling makes the system difficult to control. It's hard to determine how a system reacts by just focusing on broadcasting. Complete logic must be split under various Topics, increasing implementation complexity.

References

• "JavaScript Design Patterns"