A variant of the flyweight pattern using contextual identity. All board representation remains a bunch of uint64_t, all messages sent to boards result in bit manipulation (i.e. not massive duplication of objects), and you instantiate the piece objects once per game.
There's simply no need for "instantiate all the things" approach assumed in the Quora answer. That is OO at its most naive.
OOP is messaging, encapsulation, and late binding. What you do inside the capsule is up to you; and at a higher level, how the behaviour emerges from a composition of objects is also up to you.
I have the sinking feeling that your first paragraph is probably what the original author had in mind all along… He advocated for a representation of the entire board, and that's apparently what you would do as well.
I originally though you were advocating for a representation of each piece on the board, were "messages" were "sent" to individual pieces, not the entire board. I was curious about how you'd map that interface to a compact representation.
I am. You should definitely be able to send messages to piece objects. That's not incompatible with the Board object having a bitboard for its internal representation of board configuration. The piece objects have contextual identity based on the board configuration. Hint: they don't have positional state.
That still doesn't tell me how you map the interface to the implementation. I need a piece of code here. You won't get away buy leaving this as an exercise to the reader.
There's simply no need for "instantiate all the things" approach assumed in the Quora answer. That is OO at its most naive.
OOP is messaging, encapsulation, and late binding. What you do inside the capsule is up to you; and at a higher level, how the behaviour emerges from a composition of objects is also up to you.