Data and information hiding are a broader notions, found in computer science & software engineering. It refers to the fact that those part of a computer program that may change must not be accessible from other modules/from clients.
Encapsulation is a term that is found in Object-Oriented paradigm and refers to keeping the data in private fields and modify it only through methods.
Thus encapsulation may be seen as a way of achieving data hiding in object-oriented systems.
Cohesion refers to the degree that elements of a module belong together. The more cohesive a module is, relative to other modules in the software, the more independently it can operate. Encapsulation is one of the techniques by which cohesion can be achieved. While encapsulation is certainly an important element of cohesion, cohesion also addresses other concerns that affect cohesion.
The degree in which components depend on each other for their proper operation is called coupling. Coupling is achieved primarily by the mechanisms chosen to interact between components. The less coupled a system is, the more cohesive it is. Hence, low coupling is a desirable feature.
Let's explore a few examples of relationships between components, in order of increasing cohesivity:
Inheritance
Inheritance is very tightly-coupled, and therefore has relatively low cohesivity; if you break the inheritance, you break the program. But inheritance is desirable for systems where you want and need that kind of tight coupling, because you want the components to work closely together. It is used quite effectively in Graphical User Interfaces, for example.
Composition
Composition is less tightly-coupled than Inheritance; you can replace a local object in a class with a different implementation without breaking an inheritance chain. But you still have to change the class's internal implementation; it's just that the changes are confined to a single class.
Composition with interfaces
Here, the class is only dependent on an Interface. Consequently, you can change out the implementation without changing the class at all, provided the implementing class conforms to the specified interface. You can even change out the implementation of the interface at runtime, by handing an instance of the desired class to the constructor of your class.
Data Transfer Objects and View Models
This technique allows you to create classes that serve as data containers, without any behavior associated with them. Now, the modules between which you are communicating don't need to know anything about each other at all, not even a common interface. All they need to know about is the DTO or View Model object. But things are beginning to become a bit more complicated, because now you're spending a lot of time mapping fields to other fields and copying data between different structures.
Streams, strings and pipes
With strings and streams, you take advantage of a well-known mechanism to communicate between modules. This arrangement is the most loosely-coupled, because the module doesn't have any dependencies at all, except for widely-available, cross-platform compatible primitive data structures. Strings are the most ubiquitous of all data types; examples of their use in an API include database connection strings and communication protocols that use strings or binary arrays to transmit data. The disadvantage of this mechanism is that you now need a parser, a serializer, or some similar mechanism in your modules to translate the raw data being transmitted between modules into a usable form.
As you can see, high cohesivity isn't a perfect ideal, nor is it universally desirable. As with many other things in computing, it is a tradeoff between competing objectives.
Best Answer
Is it the right question ?
The
Mediatoris about the interactions between "colleague" objects who don't know each other. TheCommandis 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
Playerand aBoardwould make the design a little complex:PlayerandBoardwould implement the same commonColleagueinterfacePlayersends move requests toMediatorMediatorknows that player requests are to be sent toBoardBoardreceives request fromMediatorBoardanalyses request and informsMediatorthat it was accepted (or rejected)Mediatorknows that these kind of interaction are to be sent toPlayerPlayerreceives answer fromMediatorFurthermore, 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
Playersand aBoardfor example. You could add a timerColleague. You could add an adviser/coachColleagueto 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
Playerobserve theBoardstate change. And may be a secondPlayer(AI or human) would also subscribe to theBoardchange 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
Command.