Is it the right question ?
Mediator is about the interactions between "colleague" objects who don't know each other. The
Command is about how to execute one specific interaction (whether the command is created by a Player or by a mediator). The question should therefore not about which alternative to use, but how each of them could serve your purpose.
How could the Mediator help ?
The purpose of the mediator pattern is to encapsulate the interaction between several colleague objects in order to isolate them from each other. Using the mediator to decouple a
Player and a
Board would make the design a little complex:
Board would implement the same common
Player sends move requests to
Mediator knows that player requests are to be sent to
Board receives request from
Board analyses request and informs
Mediator that it was accepted (or rejected)
Mediator knows that these kind of interaction are to be sent to
Player receives answer from
Furthermore, as stated in GoF, it could be useful to make Mediator an observer to the different colleagues, so that it is informed of relevant state changes and can trigger actions.
The advantage of this more complex approach is its flexibility: you could have 2
Players and a
Board for example. You could add a timer
Colleague. You could add an adviser/coach
Colleague to inform the human player of how good his move is (or provide similar information to a machine learning AI player).
Furthermore, as the colleagues are decoupled, you could potentially reuse them in other games.
What about the Command ?
The purpose of the command pattern is to encapsulate requests. So you'd encapsulate the moves for the board and let them be executed (or reversed in case the user activates an undo).
You'd certainly use an observer pattern, to let the
Player observe the
Board state change. And may be a second
Player (AI or human) would also subscribe to the
Board change and issue commands to trigger moves. And you'd certainly have a main loop for the game, in which you could add a timer.
In the end, you would have a similar structure (game loop glues together the pieces). However, the objects need to know each other, and a change in the interaction between the objects might require adaptations of all the involved classes.
- If you want to allow an undo, you'd better use the
- If you have only two colleagues, the mediator seems a little over-engineered if you only have a single game. It further may constraint the rest of the design. So maybe start without it and refactor the code when you have something working.
- If you're interested in game coding in general, Mike McShaffry's book "Game Coding Complete" is for you : he explains how to structure a game, the challenges, and the pitfalls to avoid. There's not much theory about patterns, but a lot of common sense about working game architectures.