0 XP · 0 scenes

Mediator

Let objects talk through a middleman, not to each other
The problem

Every chat user holds references to every other user and sends messages directly.

The idea

Put the talking rules in one mediator.

Reach for it when

Many objects talk to many others in a tangle

1

The picture from life

Airplanes near an airport do not radio each other to decide who lands first. They all talk to the control tower, and the tower tells each one what to do. Adding another plane changes nothing for the others, because they only know the tower.

2

The problem

What goes wrong when you do not use it.

Every chat user holds references to every other user and sends messages directly. With ten users that is ninety links, and adding a rule like "mute" means changing all of them.

✗ Before
AshaBalaChitraknowsknowsknows
  • calls / uses
Every user knows every other user. Adding a person means updating everyone.
Reach for it when
  • Many objects talk to many others in a tangle
  • The rules of the conversation change often
  • You want to reuse objects without dragging their neighbours along
3

The idea

How the pattern fixes it.

Put the talking rules in one mediator. Each participant knows only the mediator and tells it what happened. The mediator decides who else to inform.

✓ After
AshaBalaChatRoomusersjoin(user)broadcast(sender, text)Chitrasay()
  • calls / uses
Everyone talks only to the chat room. The room decides who receives what.

Who is who

ChatRoom (mediator)
Keeps the members and delivers messages.
User (colleague)
Sends through the room, receives from the room.

Build it in steps

  1. 1Find the web of direct links.
  2. 2Create a mediator that knows all participants.
  3. 3Make participants call the mediator instead of each other.
  4. 4Put the routing rules in the mediator.
4

Watch it run

Step through the calls. Tap an arrow to jump to it.

AshaChatRoomBalaChitra1broadcast(asha, 'hi')2receive('hi')3receive('hi')
Step 1/3

Asha says hi. She talks only to the room.

broadcast(asha, 'hi')
5

The code

Python and Java. Try writing the classes yourself from the diagram first.

class ChatRoom:                                 # the mediator
    def __init__(self):
        self.members = []

    def join(self, user):
        self.members.append(user)
        user.room = self

    def broadcast(self, sender, text):
        for member in self.members:
            if member is not sender:
                member.inbox.append(f"{sender.name}: {text}")


class User:
    def __init__(self, name):
        self.name = name
        self.room = None
        self.inbox = []

    def say(self, text):
        self.room.broadcast(self, text)           # talks only to the room


def demo():
    room = ChatRoom()
    asha, bala, chitra = User("Asha"), User("Bala"), User("Chitra")
    for user in (asha, bala, chitra):
        room.join(user)
    asha.say("hi")
    return bala.inbox, chitra.inbox, asha.inbox

What you gain

  • Participants are simple and reusable
  • All the rules live in one place

What it costs

  • The mediator can become a huge god object
  • One more point of failure

You have already met it in

  • Air traffic control, chat servers, message brokers
  • Java's Timer, or MVC controllers sitting between views and models
  • UI dialogs where a form controller enables buttons based on fields

Often mixed up with

  • ObserverObserver is one-to-many broadcast; Mediator centralises many-to-many talk and its rules.
  • FacadeFacade is a one-way simplifier; a Mediator is used by the parts to talk to each other.
6

Make it stick

Build a smart-home hub: a motion sensor, lights and an alarm only talk to the hub. Add the rule "after midnight motion triggers the alarm" in the hub only.

Confidence
ObserverFacadeChain of Responsibility