NickName:David Wood Ask DateTime:2015-08-27T19:05:40

Chess in Java - Object orientation vs Efficiency

I'm developing a chess program in Java and considering the following problem:

The Rook piece requires implementation for moving in straight lines.
The Bishop piece requires implementation for moving in diagonal lines.

However,

The Queen piece requires implementation for both of the above movement patterns.

I can't think of a clean solution to modelling this relationship, I have considered some but none of them are both compliant with good object-orientated design and code efficient.

Java doesn't support multiple inheritance, so Queen cannot borrow implementation from Rook and Bishop
If Rook and Bishop extended Queen, I'd need to extract the logic for each kind of movement into separate methods, this would serious bloat my current design for how movement is validated.

Neither of the above solutions seem elegant enough to beat just:

Putting ALL of the movement implementation into the parent class of all the pieces, this way they all can share all of the common implementation (of which there is quite a bit)

I'm aware solution 3 is in violation of good Java design, but in this case, that design pattern seems to only be forcing bloated, inelegant solutions.

Probably this could be avoided with a complete restructuring of the program, but everything up to this point looks pretty efficient to me, does good OO design always come at the cost of directness of functionality and structure? Is my approach just wrong for the style of the language?

How would you solve this problem?

Copyright Notice：Content Author:「David Wood」，Reproduced under the CC 4.0 BY-SA copyright license with a link to the original source and this disclaimer.
Link to original article：https://stackoverflow.com/questions/32247718/chess-in-java-object-orientation-vs-efficiency

Answers

Rob Audenaerde 2015-08-27T11:11:54

While some classes might behave in a similar way, this does not automatically mean that they are in one hierarchy!\n\nFor example, both a Human and a Crab can move sideways, but it is silly for a Human to extend Crab.\n\nIf you really want to re-use movement code, you can use encapsulation, use a Movement type and make it like this:\n\nclass Human\n{\n List<Movement> movements;\n}\n\nclass Crab\n{\n List<Movement> movements;\n}\n\nclass MoveSideWays extends Movement\n{\n move();\n}\n\nclass MoveForward extends Movement\n{\n move();\n}\n\n\nBut it feels like over-engineering. I would have a Piece class with getPossibleMoves() and just implement it directly. There is not too much overlap and Rooks have specialized movements (Castling) as well. \n\nclass Rook extends Piece\n{\n List<Move> getPossibleMoves() {...}\n}\n\nclass Queen extends Piece\n{\n List<Move> getPossibleMoves() {...}\n}\n",

Tagir Valeev 2015-08-27T11:13:29

You should not add a superclass-subclass relations to the individual pieces. The Queen is not the special case of the Rook, neither the Rook is the special case of the Queen. They are just different pieces. You may create an interface (or an abstract class) Piece and provide different implementations like Rook, Bishop, Queen and so on.",

slartidan 2015-08-27T11:11:20

You could move both methods to the superclass, but make them protected static (you could also put those methods in a PieceHelper). In the subclasses you can then implement the adequate methods, referencing to one or the other of those methods (making them public).\n\nSuperclass:\n\nabstract class Piece {\n protected static void moveStraight(Piece p) {...}\n protected static void moveDiagonal(Piece p) {...}\n}\n\n\n(Optional) Interfaces:\n\ninterface DiagonalMover {\n void moveDiagonal();\n}\ninterface StraightMover {\n void moveStraight();\n}\n\n\nSubclasses:\n\nclass Rook extends Piece implements StraightMover {\n public void moveStraight() {Piece.moveStraight(this);}\n}\nclass Bishop extends Piece implements DiagonalMover {\n public void moveDiagonal() {Piece.moveDiagonal(this);}\n}\nclass Queen extends Piece implements StraightMover, DiagonalMover {\n public void moveStraight() {Piece.moveStraight(this);}\n public void moveDiagonal() {Piece.moveDiagonal(this);}\n}\n",

whitecoffee 2015-08-27T11:16:54

Straight line and diagonal movements are behaviors\nThus they can be modeled using interface more fittingly than inheritance\n\nRookie implements StraightMovement\n\nBishiop implements DiagonalMovement\n\nQueen implements StraightMovement,DiagonalMovement",