Welcome back to series about design pattern in JavaScript. This is an article about Mediator design pattern.
If you like topic about design pattern in JavaScript. This is link for you follow.Design pattern in JavaScript series.
Table of
contents:
- What is Mediator design pattern?
- How to implement Mediator design pattern?
- Practical application
Let’s go to
the content!
What is
Mediator design pattern?
Mediator is
a behavioral design pattern that lets you reduce chaotic dependencies between
objects. The pattern restricts direct communications between the objects and
forces to collaborate only via a mediator object.
What
problems can the Mediator design pattern solve?
Tight
coupling between a set of interacting objects should be avoided.
It should be
possible to change the interation between a set of objects independently.
Defining a
set of interacting objects by accessing and updating each other directly
inflexible because it tightly couples the objects to each other and makes it
impossible to charge the interaction independently from (without having to
change) the objects. And it steps the objects from being reusable and makes
them hard to test.
How to implement
Mediator design pattern?
 |
| Mediator UML class diagram |
Mediator: It
defines the interface for communication between colleague objects.
Concrete
Mediator: It implements the mediator interface and coordinates communication
between colleague objects.
Colleague:
It defines the interface for can communacation with other colleagues.
Concrete
Coleague: It implements the colleague interface and communicates with other
colleagues through its mediator.
Practical
application
To understand more about Mediator design pattern. Let's go to the same problem. You are making a simple chat app for users. Clients can interact with each other through messages.
 |
| Network of clients |
As you can
see in the image above, clients interact directly with each other. This will
increase the speed of sending messages between two parties. But in this network,
we only have five clients, the network looks pretty messed up. What if our
system is bigger and more users? Managing the system and clients will be more
difficult. Worse, there will be bugs that we don't want.
Let's use
the Mediator design pattern to solve this problem. Look at the picture below.
 |
| Network has chatroom |
We have a
common chatroom to manage connections between clients. Messages will go through
the chatroom before reaching the recipient. This will make the message
transmission speed slower because it has to go through the chatroom for
processing. But you can see that the network has been cleaner, no longer looks
as complicated as before. So how will the application to the code be?
function Member(name) {
this.name = name
this.chatroom = null
}
First, we
define a Member object that takes a name and has the chatroom null.
Member.prototype = {
send: function (message, toMember) {
this.chatroom.send(message, this, toMember)
},
receive: function (message, fromMember) {
console.log(`From: ${fromMember.name} - ${message} - To: ${this.name}`)
}
}
Next, we
define two methods for Member, the send() method, whose purpose is to send a
message to the recipient. And the receive() method every time a message
arrives, it will know who the sender is and the content of the message.
function Chatroom() {
this.members = {}
}
We define a
Chatroom object, which stores information about clients through an object
called members.
Chatroom.prototype = {
addMember: function (member) {
this.members[member.name] = member
member.chatroom = this
},
send: function (message, fromMember, toMember) {
toMember.receive(message, fromMember)
}
}
The method
in the chat room will be the addMember() method to add users to the system. The
send() method is a method for members to call and send messages. When executed,
the recipient will be automatically updated with the new message.
const chatroom = new Chatroom()
const client1 = new Member('client 1')
const client2 = new Member('client 2')
const client3 = new Member('client 3')
We start creating
a chatroom and three clients to test the program.
chatroom.addMember(client1)
chatroom.addMember(client2)
chatroom.addMember(client3)
Chatroom
will add members and we will start using the system to see if it is working
properly.
client1.send('Hey chat room!', client2)
// => From: client 1 - Hey chat room! - To:
client 2
client2.send('Hey men!', client1)
// => From: client 2 - Hey men! - To:
client 1
client3.send('How are you today?', client1)
// => From: client 3 - How are you today? -
To: client 1
Awesome! We
have created a simple chat app with the function of sending messages between
clients. Let's analyze how the Mediator design pattern has its cons and pros.
Single
Responsibility Principle. You can extract the communications between various
components into a single place, making it easier to comprehend and maintain.
Open/Closed
Principle. You can introduce new mediators without having to change actual
components.
You can
reduce coupling between various components of a program.
You can
resuse individual component more easily.
Cons
Overtime a
mediator can evolve into a God Object.
Conclusion
We just
created a chat app using the Mediator design pattern and analyzed the pros and
cons. If your program needs communication between components, you can consider
using the Mediator design pattern to improve your system.
0 Nhận xét