Inheritance vs Composition For Chess Pieces

Question

A quick search of this stackexchange shows that in general composition is generally considered more flexible than inheritance but as always it depends on the project etc and there are times when inheritance is the better choice. I want to make a 3D chess game where each piece has a mesh, possibly different animations and so on. In this concrete example it seems like you could argue a case for both approaches am I wrong?

Inheritance would look something like this (with proper constructor etc)

class BasePiece
{
    virtual Squares GetValidMoveSquares() = 0;
    Mesh* mesh;
    // Other fields
}

class Pawn : public BasePiece
{
   Squares GetValidMoveSquares() override;
}

which certainly obeys the "is-a" principle whereas composition would look something like this

class MovementComponent
{
    virtual Squares GetValidMoveSquares() = 0;
}

class PawnMovementComponent
{
     Squares GetValidMoveSquares() override;
}

enum class Type
{
     PAWN,
     BISHOP, //etc
}


class Piece
{
    MovementComponent* movementComponent;
    MeshComponent* mesh;
    Type type;
    // Other fields
 }

Is it more a matter of personal preference or is one approach clearly a smarter choice than the other here?

EDIT: I think I learned something from every answer so I feel bad for only picking one. My final solution will take inspiration from several of the posts here (still working on it). Thanks to everyone who took the time to answer.

Answer 1

At a first glance, your answer pretends the "composition" solution does not use inheritance. But I guess you simply forgot to add this:

class PawnMovementComponent : MovementComponent
{
     Squares GetValidMoveSquares() override;
}

(and more of these derivations, one for each of the six piece types). Now this looks more like the classical "Strategy" pattern, and it is also utilizing inheritance.

Unfortunately, this solution has a flaw: each Piece now holds it's type information redundantly twice:

• inside the member variable type

• inside movementComponent (represened by the subtype)

This redundancy is what could really bring you into trouble - a simple class like a Piece should provide a "single source of truth", not two sources.

Of course, you could try to store the type information only in type, and create no child classes of MovementComponent as well. But this design would most probably lead to a huge "switch(type)" statement in the implementation of GetValidMoveSquares. And that is definitely a strong indication for inheritance being the better choice here.

Note in the "inheritance" design, it is quite easy to provide the "type" field in a non-redundant way: add a virtual method GetType() to BasePiece and implement it accordingly in each base class.

Concerning "promotion": I am here with @svidgen, I find the arguments presented in @TheCatWhisperer's answer debatable.

Interpreting "promotion" as a physical exchange of pieces instead of interpreting it as a change of the type of the same piece feels quite more natural to me. So implementing this as in a similar manner - by exchanging one piece by another of a different type - will most probably not cause any huge problems - at least not for the specific case of chess.

Answer 2

I'd probably prefer the simpler option unless you have explicit, well-articulated reasons or strong extensibility and maintenance concerns.

The inheritance option is fewer line of code and less complexity. Each type of piece has an "immutable" 1-to-1 relationship with its movement characteristics. (Unlike it's representation, which is 1-to-1, but not necessarily immutable — you might want to offer various "skins".)

If you break this immutable 1-to-1 relationship between pieces and their behavior/movement into multiple classes, you're probably only adding complexity — and not much else. So, if I were reviewing or inheriting that code, I'd expect to see good, documented reasons for the complexity.

All that said, an even simpler option, IMO, is to create a Piece interface that your individual Pieces implement. In most languages, this is actually very different from inheritance, because an interface will not restrict you from implementing another interface. ... You just don't get any base class behavior for free in that case: You'd want to put shared behavior somewhere else.

Answer 3

The thing with chess is that the game play and piece rules are prescribed and fixed.  Any design that works is fine — use whatever you like!  Experiment and try them all.

In the business world, however, nothing is so strictly prescribed like this — business rules & requirements change over time, and programs have to change over time to accommodate.  This is where is-a vs. has-a vs. data make a difference.  Here, simplicity make complex solutions easier to maintain over time and changing requirements.  In general, in business, we also have to deal with persistence, which may involve a database as well.  So, we have rules like don't use multiple classes when a single class will do the job, and, don't use inheritance when composition is sufficient.  But these rules are all geared toward making the code maintainable over the long run in the face of changing rules & requirements — which is just not the case with chess.

With chess, the most likely long term maintenance path is that your program needs to get smarter and smarter, which eventually means speed and storage optimizations will dominate.  For that, you will generally have to make trade offs that sacrifice readability for performance, and so even the best OO design will eventually go by the wayside.

Answer 4

I would start by making some observations about the problem domain (i.e. rules of chess):

• The set of valid moves for a piece depends not just on the type of the piece but the state of the board (pawn can move forward if the square is empty / can move diagonally if capturing a piece).
• Certain actions involve removing an existing piece from play (promotion / capturing a piece) or moving multiple pieces (castling).

These are awkward to model as a responsibility of the piece itself, and neither inheritance nor composition feels great here. It would be more natural to model these rules as first-class citizens:

// pseudo-code, not pure C++

interface MovementRule {
  set<Square> getValidMoves(Board board, Square from); // what moves can I make from the given square?
  void makeMove(Board board, Square from, Square to); // update board state to reflect a specific move
}

class Game {
  Board board;
  map<PieceType, MovementRule> rules;
}

MovementRule is a simple but flexible interface that allows implementations to update the board state in any way required to support complex moves such as castling and promotion. For standard chess, you would have one implementation for each type of piece, but you can also plug in different rules in a Game instance to support different variants of chess.

Answer 5

I would think in this instance inheritance would be the cleaner choice. Composition might be a little more elegant, but it seems to me to be a little more forced.

If you were planning on developing other games that use moving pieces that behave differently, composition might be a better choice, especially if you employed a factory pattern to generate the pieces needed for each game.

Answer 6

From my point of view, with the information provided, it is not wise to answer whether inheritance or composition should be the way to go.

• Inheritance and composition are just tools in the object-oriented designer's toolbelt.
• You can use these tools to design many different models for the domain of the problem.
• Since there are many such models that can represent a domain, depending on the designer's point of view of the requirements, you can combine inheritance and composition in multiple ways to come up with functionally equivalent models.

Your models are totally different, in the first one you modeled around the concept of chess pieces, in the second one around the concept of movement of the pieces. They might be functionally equivalent, and I would choose the one that represents the domain better and helps me reason about it more easily.

Also, in your second design, the fact that your Piece class has a type field, clearly reveals there is a design problem here since the piece itself can be of multiple types. Doesn't it sound like this should probably use some sort of inheritance, where the piece itself is the type?

So, you see, it is very hard to argue about your solution. What matters is not whether you used inheritance or composition, but whether your model reflects accurately the domain of the problem and if it is useful to reason about it and provide an implementation of it.

It takes some experience to use inheritance and composition properly, but they are entirely different tools and I don't believe one can "substitute" one with the other, although I can agree that a system could be designed entirely using just composition.

Answer 7

which certainly obeys the "is-a" principle

Right, so you use inheritance. You can still compose away within your Piece class but at least you will have a backbone. Composition is more flexible but flexibility is overrated, in general, and certainly in this case because the chances of someone introducing a new kind of piece that would require you to abandon your rigid model are zero. The chess game is not going to change anytime soon. Inheritance gives you a guiding model, something to relate too, teaching code, direction. Composition not so much, the most important domain entities do not stand out, it is spineless, you have to understand the game in order to understand the code.

Answer 8

Please do not use inheritance here. While the other answers certainly have many gems of wisdom, using inheritance here would certainly be a mistake. Using composition not only helps you deal with issues you do not anticipate, but I already see a problem here that inheritance can not handle gracefully.

Promotion, when a pawn gets converted to a more valuable piece, could be an issue with inheritance. Technically, you could deal with this by replacing one piece with another, but this approach has limitations. One of these limitations would be tracking per piece statistics where you might not want to reset the piece information upon promotion (or write the extra code to copy them over).

Now, as far as your composition design in your question, I think it is unnecessarily complicated. I don't suspect you need to have a separate component for each action and could stick to one class per piece type. The type enum might also be unneeded.

I would define a Piece class (as you already have), as well as a PieceType class. The PieceType class defines all the methods which a pawn, queen, ect must define, such as, CanMoveTo, GetPieceTypeName, ect. Then the Pawn and Queen, ect classes would virtually inherit from the PieceType class.

Answer 9

Well, I suggest neither.

While object-orientation is a nice tool, and often helps simplify things, it is not the only tool in the toolshed.

Consider implementing a board class instead, containing a simple bytearray.
Interpreting it, and calculate things on it is done in the member-functions using bit-masking and switching.

Use the MSB for the owner, leaving 7 bits for the piece, though reserve zero for empty.
Alternatively, zero for empty, sign for the owner, absolute value for the piece.

If you want, you could use bitfields to avoid manual masking, though they are unportable:

class field {
    signed char data = 0;
public:
    constexpr field() = default;
    constexpr field(bool black, piece x) noexcept
    : data(x < piece::pawn || x > piece::king ? 0 : (black << 7) | x))
    {}
    constexpr bool is_black() noexcept { return data < 0; }
    constexpr bool is_white() noexcept { return data > 0; }
    constexpr bool empty() noexcept { return data == 0; }
    constexpr piece piece() noexcept { return piece(data & 0x7f); }
};