You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
14 lines
1.0 KiB
14 lines
1.0 KiB
Design change to the Move class:
|
|
Two things that felt wrong:
|
|
1) Some Move objects will be half-constructed temporarily (move history) or permanently (enumeration of legal moves)
|
|
2) A Move object can't determine by itself which piece moved, whether it was a capture, check, checkmate, or stalemate.
|
|
What if we recompute the notation whenever needed, on the fly?
|
|
* Depending on the GUI implementation, making n moves may result in O(n^2) notation calculations
|
|
Observations:
|
|
* Whoever determines move notation needs to know the relevant board states and the move itself (the Chess class).
|
|
* Move notation can be stored as such; it isn't necessary to have 3 or 4 boolean variables for check, capture, etc.
|
|
* Move notation should be cached to avoid recalculations and potential O(n^2)-time behavior
|
|
Conclusion:
|
|
Put it in the Chess class, because we have access to the relevant board states and the move itself.
|
|
[Maybe the parallel arrays in the Chess class can be made into a single array of Turn objects...]
|