Timeline for A chess engine in Java: generating white pawn moves - take II
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 20, 2024 at 16:39 | comment | added | Alexander Ivanchenko | @SimonForsberg And taking into account that it's not the most juicy part of this project (since OP's ultimate goal is to create a chess engine), it's even more important to reduce the coupling and simplify these bare-bones elements, in order to make debugging and testing easier. | |
| Sep 20, 2024 at 16:39 | comment | added | Alexander Ivanchenko |
@SimonForsberg Also, method Piece.move() will be triggering changes in the state of the Boar and its own state (I assume that a piece that knows how it can move is stateful) and potentially the state of another piece. Imaging how castling might look like is such a scenario... Making only one component responsible for moving pieces will make the implementation cleaner and simpler.
|
|
| Sep 20, 2024 at 16:38 | comment | added | Alexander Ivanchenko |
@SimonForsberg Sorry, I often miss comments. Probably, I didn't explain well the point regarding moving pieces (updated the answer). In short, if we introduce the functionality for making move into the Piece class, it'll lead to a tight coupling between Piece and Board and the logic describing a move will be split between these classes. Because it's not possible to make move() implementation in Piece self-sufficient, it'll depend on the information from Board.
|
|
| Sep 20, 2024 at 16:38 | history | edited | Alexander Ivanchenko | CC BY-SA 4.0 |
added 2512 characters in body
|
| Jul 30, 2024 at 22:17 | comment | added | Simon Forsberg |
Regarding "then why spawning new instances?" - I don't think it's necessarily a bad thing to spawn new instances. Conceptually, two instances of Piece can represent that those are representations of two different physical pieces. And it does make it easier to refactor if at some point in the future a piece would have the move method etc. on it. Spawning new instances isn't necessarily a bad thing, I'd rather have that than jumping through hoops to re-use the same instance(s) (e.g. during pawn promotion). Otherwise, still an excellent answer! +1
|
|
| Jul 11, 2024 at 15:56 | comment | added | Alexander Ivanchenko | @vnp OP's pieces are not aware of their positions on the board. If you're advising to change this, then I already shared my opinion on such a design decision in the answer. The board should be responsible for describing positions of the pieces, and the board can track the history of moves. And a separate component should be tasked with analyzing the board state (like determining whether it's a check, checkmate, or draw), not a board. | |
| Jul 11, 2024 at 15:55 | comment | added | Alexander Ivanchenko |
@vnp There's no difference between instances of Piece of the same color and type because type, color and expander are their only attributes (see how pieces instantiated in the question and Piece definition in the OP's repository).
|
|
| Jul 2, 2024 at 22:10 | comment | added | vnp | "What's the difference between two instances of Piece with the same type and color? There's none." In fact, there is, although quite a subtle one: if such pieces change places, the resulting board is different from the original, and a three-fold repetition rule does not apply. In case I've misread you, my apologies. | |
| Jul 2, 2024 at 17:13 | history | edited | Alexander Ivanchenko | CC BY-SA 4.0 |
added 5 characters in body
|
| Jul 2, 2024 at 17:05 | history | edited | Alexander Ivanchenko | CC BY-SA 4.0 |
added 989 characters in body
|
| Jul 1, 2024 at 17:11 | history | edited | J_H | CC BY-SA 4.0 |
minor grammar
|
| Jul 1, 2024 at 16:08 | history | edited | Alexander Ivanchenko | CC BY-SA 4.0 |
added 181 characters in body
|
| Jul 1, 2024 at 15:48 | history | edited | J_H | CC BY-SA 4.0 |
typo: "stile"
|
| Jul 1, 2024 at 15:41 | history | answered | Alexander Ivanchenko | CC BY-SA 4.0 |