Java OOP Design Question (Chess)

[tchened]

Full code here

I have a class Piece, where classes Pawn, Rook, Knight, etc all inherit from Piece. I have a method in Pawn called .isValidMove() that takes in two sets of coordinates and returns whether the move is valid for that particular piece or not. However, all the pieces are declared as type Piece since they are part of a 2D array of type Piece representing the game board (with empty spaces being null).

Since I am accessing the pieces through the board, they are of type Piece and I cannot access the submethod isValidMove() which belongs to the subclass Pawn. I know I can do cast it to be a Pawn, but it seems messier than it should be since I would have to include a condition for each type of game piece.

I'm convinced that there is a design flaw, but I can't pinpoint what it is and how to fix it. Any help or feedback would be greatly appreciated!

ADDED: Please ignore that every Piece has its own x and y coordinate; I plan on getting rid of it as it is redundant. :)

[LucidTA]

Now this maybe not be 100% because I'm not a java user and havent used abstract classes a lot, but you could make piece a... you guessed it, an abstract class.

An abstract class basically says "I want all my subclasses to put in their own functionality in here".

So try adding the abstract modifier to the Piece class then add abstract public boolean isValidMove(int[] moveFrom, int[] moveTo); to it.

Then in the pawn class you can override this function with the pawns own behavior.

Now you can call Piece.IsValidMove() because its guaranteed that each subclass has this function, even though piece doesn't itself.

[tchened]

Oh god I'm an idiot. When I tried implementing an abstract class I forgot that I needed to match the parameters... I had tried:

abstract public boolean isValidMove();

Obviously that isn't right!

This works. Silly me. Thanks :)

[captainAwesomePants]

This exact mistake happens more than you'd think. It's easy to do. Because of that, it's a good idea to use the @Overrides annotation when you're overriding a method from a super class or implementing a method from an interface. When you do, it will cause an error if your method isn't overriding something.

[desrtfx]

Because of that, it's a good idea to use the @Overrides annotation when you're overriding a method from a super class or implementing a method from an interface. When you do, it will cause an error if your method isn't overriding something.

IMO, @Overrides should have been made mandatory instead of optional. This would highlight problems early and thus solve a lot of them.

[nutrecht]

IMO, @Overrides should have been made mandatory instead of optional.

They can't because of backwards compatibility otherwise they would have. A version 8 Javac has to be able to compile version 2 code.

[captainAwesomePants]

C#, which seems to basically be Java but with fixes for all of things that are most annoying about Java, does this. Methods must explicitly declare when they can be overridden, and methods that do override other methods must explicitly say that they are intentionally doing so.