What is a good way to model two objects that are the same thing, but have two different functionalities?

Question

I am looking for a good way to model a 'move' in a board game. I want to be able to ask a Player what their move is and have them respond, then be able to perform the correct actions on the board based on their move. The problem is, there are several types of moves, each with its own set of data. For example, in Scrabble, you can play a word, which should return the word, its position and direction (or a set of tiles with positions or whatever), but you can also swap tiles (which would involve returning the tiles you want to swap) or pass.

Similarly in chess, you normally move a piece, which should return a move with the piece and where it goes, but you could also castle, which involves indicating two pieces and their positions, or a side (king/queen), or some other piece of information besides piece/position.

I'm assuming that a Player returning a Move object is the best way to go, but I'm open to any other modeling choices or suggestions as well.

Thanks!

Answer 1

As a rule of thumb, if you want to have common type but different behavior for a thing - here a Move - you need to let the thing implement the behavior. So instead of asking how the board can interpret two different moves differently, you should consider how to have two different moves use the board differently when performing their move.

So: The base class (should probably be interface) is a Move, it has a perform() method, and the two kinds of moves have different implementations of the perform() method.

Answer 2

These may not be exactly what you are looking for, but there seems to be a lot of great ideas on this old post:

Any patterns for modelling board games?

Some of the answers include suggestions for Move implementations, and could hopefully give you some new ideas.

Answer 3

A good model is always based on the detailed knowledge of requirements, data flow, control flow, overall system architecture, and so on. It is not very fruitful to design an application by handwaving and philosophical argument.

Concerning your particular question, one of generally legitimate models is for the Player to return a Move, but depending on full details, its actual merit may range from a total success to a total disaster.

Answer 4

A move in a game is not really an object. It's an event.

Your chess example is the easiest. A move returns a piece and new position on the board, but it could also return a castle event, a capture event, and / or a piece promotion event.

Similarly, in a Scrabble game, a move could return a word play event, a exchange tile event, or a pass event.

Think of an event as a message to the rest of the game. You can code an event as you would a class. This event class would have to have access to the various game classes so that the model could create the message.

An event handler class processes all of the game events. This class would be the class that manipulates the other game classes. The events would just have to all be in a format that the event handler could handle.

Answer 5

If different implementations will have nothing in common other than how they present themselves to the outside world, which sort of comes across from your explanation, Move should be a loosely defined interface with each implementation across different games doing its own thing.

But my main question is whether there really is a reason to have this interface known across different games. If there is not a shared handler of some sort, which expects certain action formats across different games, I would not bother and simply define different game-specific Move classes.