Exploring the Mediator Pattern
After completing all the features for a command line version of Tic Tac Toe, I was asked by my mentors to implement a desktop application version using JavaFX. I was challenged to reuse as much of my core game logic as possible.
A Tale of Two Programming Models
A tricky problem here is that the Command line UI follows a synchronous model (the game and the UI send and receive messages one after the other) but a JavaFx UI is fundamentally asynchronous (the UI has to still operate in the background but can send values back to the game at any time — in response to something like a user click).
The design of my application then needed something like this:
- My
Gameneeds a single way of notifying aUIof changes and receiving values back from it. - A
UIshould be able to receive instructions from theGameand send back values in whichever programming model it chooses to.
Coupling my Game so tightly to a UI seemed like a bad idea but they still need a way of talking! This thought reminded me of how Elm and JavaScript communicate with each other — Elm has a concept of ports which broker the communication between JavaScript and back (it’s a clever technique based on the Actor Model that keeps Elm and JavaScript isolated from each other).
Could I make an object that’s only responsibility was to broker the communication between my Game and a UI? After googling around, I stumbled across the Mediator pattern:
What is a Mediator?
[The mediator pattern] defines an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently¹
Well that sounds promising. An example used in Java Design Patterns³ is a piece of software that models a washing machine. The washing machine has many parts (like a heater, motor, sensors and valves) that need to talk to one another for the washing machine to work. The suggestion is to have each of the parts talk only with a mediator, and that class decide which other parts to inform as a result of that message.
Tic Tac Toe Mediator
I ended up with an abstract class like this:
I encoded how information would be sent back to the game, but left it up to each UI how they would choose to deal with instructions. A nice effect of this design is that it can handle both synchronous and asynchronous models, e.g for the console I can request a move like so:
@Override
public void requestMoveFromUI(Board board, PlayerSymbol playerSymbol) {
int move = console.requestMove(board, playerSymbol);
receiveMove(move);
}The console sends the synchronous value straight back to the game via the receive method.
And in the JavaFX version:
@Override
public void requestMoveFromUI(Board board, PlayerSymbol playerSymbol) {
renderCurrentBoard(board);
}The current board is rendered where the user can choose to click on a tile. And on each tile:
public void onClick(Consumer<Integer> moveReceiver) {
this.setOnMouseClicked(e -> {
if (tile.isEmpty()) {
moveReceiver.accept(tile.getIndex());
}
});
}The Consumer<Integer> moveReceiver is a reference to the Mediator’s receiveMove method, so the move gets sent back to the game when a user clicks on a tile.
Overall I was quite surprised how flexible and pleasant to work with this design was. I ended up with a pretty snazzy looking JavaFX app that was easy to customise the behaviour and to test it.
But, is it a Mediator?
One of my mentors after looking at my code asked me: “is it a mediator?” Unlike many of the examples it only handles communication between two objects, and sits in a very similar place to a Controller in the MVC (Model, View, Controller) pattern. Is it a thin Controller?
A controller translates interactions with the view into actions to be performed by the model⁴
From this definition it could definitely be called a controller. I think it’s still valid to call it a mediator as it’s only responsibility is to funnel messages back and forth from the UI and the Game. But maybe it would be more sensible to just call it a Controller due to the fact it’s only managing two objects. I’d be interested to hear thoughts on this though.
Conclusion
Whether it’s technically a mediator or not, it’s been an interesting experience spending some time exploring this pattern. The main takeaways are to use the mediator pattern when…
- A set of objects communicate in well-defined but complex ways.¹
- Reusing an object is difficult because it refers to and communicates with many other objects.¹
- A behaviour that’s distributed between several classes should be customisable without a lot of subclassing.¹
At any rate, I’ve been able to experience first hand how designing with loose coupling in mind leads to a more pleasant to work with software.
