Is it the right question ?
The 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:
Player
and Board
would implement the same common Colleague
interface
Player
sends move requests to Mediator
Mediator
knows that player requests are to be sent to Board
Board
receives request from Mediator
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
Player
receives answer from Mediator
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.
Recommendations
- If you want to allow an undo, you'd better use the
Command
.
- 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.
undo
methods and state as well to the command interface so that the opposite action can be performed.undo
potential in aMoveCommand
is going to be useful for me. Follow up question: Could a command object reference strategy objects? Like if a player moves a certain piece, the specific move behavior is dependent on the type of piece being moved, each move type being encapsualted in a strategy object