Timeline for How to handle subclasses needing different method signatures for the overriden function?
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 15, 2022 at 12:28 | answer | added | gnasher729 | timeline score: 1 | |
| Aug 15, 2022 at 5:12 | review | Close votes | |||
| Aug 20, 2022 at 3:04 | |||||
| Aug 14, 2022 at 19:40 | comment | added | Yoh | @DocBrown I agree, isMoveValid shouldn't capture, I am just trying to connect the dots is all, isMoveValid should take in account that a capture might occur, since moving diagonally on a capture for a pawn is a valid move but isn't in any other scenario, I most likely would use it in the move method and let it capture, as in move to a certain Square, but if the square has an opponent piece then it means to capture. yPosDifference and xPosDifference are required to ensure that the position of the enemy piece is diagonal to the piece doing the moving/capturing. | |
| Aug 14, 2022 at 19:24 | comment | added | Doc Brown | ... and besides that - consider to redesign isMoveValid not to execute any capturing on the board - a method which tests something should not secretly change the board's state. | |
| Aug 14, 2022 at 19:22 | comment | added | Doc Brown | ... and concerning the "duplicate code": if you have duplicate code in two methods, refactor it out into a separate method which can be called from the two former ones. Don't be afraid of the same calculation happening twice, that's a negligible performance impact. | |
| Aug 14, 2022 at 19:19 | comment | added | Doc Brown | But where do you intend to call willCapture? Why does it have to be an abstract method with a common signature? Why does it really require parameters yPosDifference and xPosDifference? For checking if a pawn will capture a piece, one only need the "future position", as well as for any other piece. There seems to something wrong in your function's logic, but I cannot tell you really what it is since you don't gave us the full picture. | |
| Aug 14, 2022 at 19:19 | comment | added | Martin Maat | It seems to me you are defeating the purpose of polymorphism by leaving the burden of calling all these methods in the right way up to the client of the piece. Why not just have a Piece.Move(newPosition) method (may be with an extra parameter that tells whether to actually perform the move or not) that returns a report? Like Success or Failure with the reason for failing? That would make all your troubles disappear. | |
| Aug 14, 2022 at 18:50 | comment | added | Yoh | The issue is the arguments of willCapture() that's why I didn't add any, in the case of the Queen it would be willCapture(Square futurePosition) in the case of a pawn it would be willCapture(Square futurePosition, int yPosDifference, int xPosDifference) or willCapture(Square futurePosition) and recalculate yPosDifference and xPosDifference inside the method, which will result in duplicate code since they were already calculated in isMoveValid() capture calls Board.getBoard().removePieceFromBoard(capturedPiece); but with some print statements for debugging. | |
| Aug 14, 2022 at 18:40 | comment | added | Doc Brown | ... and what does capture do? That name puzzles me, because isMoveValid should only test if a move is valid, I guess, not change the state of the board in any way. | |
| Aug 14, 2022 at 18:31 | comment | added | Doc Brown | Your example still misses the crucial part you were asking about, the intended signatures of willCapture - come on - that is the core of your question, and you are holding this back? I think you can do better, | |
| Aug 14, 2022 at 18:17 | answer | added | Christophe | timeline score: 6 | |
| Aug 14, 2022 at 18:15 | comment | added | Peter M | I see an issue with your separation in that I believe that in some circumstances isMoveValid() and willCapture() are related and need to exchange information. In the case of a pawn, a diagonal move is only valid, if it is capturing a piece. | |
| Aug 14, 2022 at 18:00 | answer | added | IMSoP | timeline score: 0 | |
| Aug 14, 2022 at 17:52 | history | edited | Yoh | CC BY-SA 4.0 | deleted 5 characters in body |
| Aug 14, 2022 at 17:48 | comment | added | Yoh | Edited the question, now has code snippets. @DocBrown it is there to avoid a player moving a piece that aren't theirs. if (this.getColor() != color) throw new IllegalArgumentException("The piece chosen was not your piece."); It takes the current player's color (i.e white or black) and checks if the color of the current piece is the same as the player. I probably should rename the parameter. | |
| Aug 14, 2022 at 17:46 | history | edited | Yoh | CC BY-SA 4.0 | added 1543 characters in body |
| Aug 14, 2022 at 17:40 | comment | added | Doc Brown | ... and why does ChessPiece.isMoveValid require a piece color as parameter? I guess a chess piece should know its color already. | |
| Aug 14, 2022 at 17:31 | comment | added | Doc Brown | "some values needed for the logic are already calculated in isMoveValid()"- " but some pieces do not need those values". Could you please tell us precisely which values, or give an example where we can actually see your issue? | |
| S Aug 14, 2022 at 14:20 | review | First questions | |||
| Aug 14, 2022 at 18:22 | |||||
| S Aug 14, 2022 at 14:20 | history | asked | Yoh | CC BY-SA 4.0 |