[tel]

The Bitboard is very abstract. The interface it instantiates will likely not let leak it’s concise internal representation and will discuss the operations on the game state at a domain level. This is abstraction.

So this is a failure of OO abstraction. Why? OO abstraction is really complex and makes many forced moves that provide little value here. Inheritance and a focus on “nouns” makes idiomatic code highly specialized to certain domain models. Unfortunately, these are rarely useful.

[qznc]

OO design is often about the tradeoff between over-engineering and over-specialization. The rules of chess can usually be assumed to not changed, which is different to most programming tasks.

If you would design for Chess 2.0 and you expect some game designers to change the rules every week (thinking up new kinds of pieces, changing the rules for existing pieces, changing the board layout, etc), would you still use Bitboard? Maybe it would be better to focus on the "nouns" the game designers use and keep optimizations like BitBoard in mind for later?

[tel]

The point of abstraction is to not be tied to Bitboard--or any concrete representation whatsoever. Chess 2.0 changing its rules is exactly what can be protected against.

[qznc]

Yes in theory.

In practice, if code uses a Queen object, you put costly indirections in front of the Bitboard and thus already lost performance.

[tel]

You assume a Queen object and also some compiler details. These might be in practice relevant some of the time but (a) how often, really? And (b) are those forced decisions or decisions of convenience and momentum?

Fwiw, as soon as you say “object” I’m betting you’re taking on expensive, unnecessary OO mental modeling.