[johnfn]

The OP has translated the interviewers question of "design a readable and maintainable abstraction for a chessboard" into "design the most space-optimized chessboard possible", then wonders why the interviewer doesn't like his solution.

[smallnamespace]

Or maybe the OP understood that everyone who has ever implemented a chessboard are also building chess engines where memory efficiency and speed actually matter a lot.

It's the interviewers who are ignorant here, they took a real problem and translated it badly into a toy problem. Then they failed to realize what they did.

[lozenge]

They could be building an online social game site, or implementing a UI but using an existing AI. In which case the OO version will be easier to code, understand, render, and render history in chess notation. The only thing his methods is good for is implementing an AI and serialization.

[christophilus]

I think the author's approach is data-centric rather than object-centric.

His methods would be easy to persist: write the longs to a file. Easy to render: based on bit positions, draw a piece. Easy to understand. I looked at it and immediately knew what was happening (which almost never happens when I have to look at a massive class hierarchy). History would be trivial with his approach: since it's space-efficient, you could literally store the bit-space for each previous board configuration or if you wanted to optimize more, you could store a simple sequence of moves.

[ZirconiumX]

I highly disagree. Implementing an AI requires being able to work effectively in chess notation. Either you can choose long algebraic notation, which is pure squares (which can be encoded/decoded into a move type) or short algebraic notation, which requires knowing piece types (which is an AND between a bit representing the square and piece type bitboards) and being able to differentiate between multiple attacks to a square (which is an AND between the move square and attacks by other pieces of the same type).

This is complicated by the two approaches not being apples-to-apples, however.

[fjdfhdjldj]

why? the bitBoard describes the full game state, your renderer can use the data to draw the board for seamless decoupling.

I don't see how the history would make any difference?

bitshifting might be a bit hard for newer programmers but it's abstracted under global functions.

[inopinatus]

GP is correct. The Quora answer has a false dilemma that you've just perpetuated here, viz. that an OO program cannot use a compact representation. But there are standard patterns for using a compact representation of data for domain-model objects.

The article's author isn't just unaware of them, they've written a petulant, arrogant article demonstrating their own lack of experience and adaptability.

[loup-vaillant]

I'm interested. Care to elaborate how an OO approach could yield a compact representation in this particular case?

[rrobukef]

A facade wrapping the representation would sufficiently transform the paradigm?

[mnm1]

Oh please. As if the interviewer's next question wouldn't be "make it faster/more efficient" anyway. The interviewer is the problem here because he wants to build a chess game in an extremely stupid way using OOP for no other reason than to use OOP. I'd say most applications of OOP fail in similar ways in real life, creating monsters of complexity where simplicity could have existed. The author should consider himself lucky: this sounds like an extremely shitty company and the interview has shown him that. It probably wouldn't even be worth it for him to complete the interview at this point. No one wants to work for idiots.

[valuearb]

The interviewer gave the OP a simple question that could be answered within a short time to gauge how well they understood OO design, and OP specifically implemented it in a way to frustrate them. So again, whose the idiot?

If OP wanted to crush the question, they could quickly answer it by saying this is how you could implement using classes and inheritance, now let me explain why OO is a poor solution for this specific problem, and what kind of problem sets OO design is most useful in.

[loup-vaillant]

How the interviewee is supposed to even guess this is an OOP question, as opposed to a "solve this problem" question? Unless the interviewer goes out of his way to mandate an OOP solution, he will just get whatever is the best guess of the interviewee.

In my case, this is unlikely to yield an OOP solution. I'm even less likely to guess an OOP solution was even expected. And if I fail the interview because this particular company takes OOP for granted, I should fail the interview, and may even be glad I did.

[zephyrfalcon]

It does not mention how the question was put, and in which context. If it was clear from the start that the OP was expected to use OO, then it would not be smart to start with the bitboard implementation and then continue to argue about it. ... But if the question simply was, "how would you design a chess game", with no other context, then it would be reasonable to assume that the interviewer would want to hear your best solution... and for that he chose the non-OO bitboard version, based on his previous experience with chess engines.

[alerighi]

That is entirely subjective. I am more comfortable reasoning with bits than with object.

I also think optimization matters, if you can reduce the memory consumption with a simple and elegant solution, why not ?

[fjsolwmv]

How would you build a GUI for your bits-based chessboard?

[christophilus]

Trivially, you'd iterate i from 0-63 and then do 10 bit checks per value of i in order to determine what piece, if any, is on tile i. You could probably optimize it further, but that'd be hella fast on any device I can think of, and would take very little code to implement.

[fjdfhdjldj]

for each type of piece if the bit is set, draw the piece at that position.

if you click on a square and there is a piece in that square( there is a bit set in that position in any of the types), get the valid moves and draw them.

if then you click an empty valid space, render the piece moving.etc..

most of the details are usually hidden behind functions. You renderer should not care about the internal representation of your data.

[Sinidir]

Yeah during reading this i was wondering how someone can miss the point to that kind of degree. The point was to test for an understanding of object-oriented design. Yet he talks about how awesomely space effiencient his implmementation is compared to using objects.

But the interviewers seemed to also miss the ball, making irrelevant and false objections.

[Silhouette]

It's a poor choice of scenario for an interview, because no-one who knew anything about writing chess software would ever write that sort of OO code. If the point was to test for an understanding of OO design, wouldn't it be a good idea to provide a problem where OO design was appropriate?

[fjsolwmv]

OO is for large problems, not 30-line whiteboard able problems. That's the challenge.

[Silhouette]

Is there any reason to believe that code using efficient data representations like bitboards can't scale just as well, if not better, than OO versions full of classes?

Or that the interface to use that code would be harder to understand or maintain?

If not, why mandate the use of OO at all, and if it's OO you want to test, why not pick a better example where it might actually make sense?

[andrewflnr]

The OP specifically addressed your objection. Write some helper functions if you're worried about maintainability.