RoadieRich wrote:The key to basic OOP is the "has-a" and "is-a" relationships. The board "has a" (number of) chess pieces on it, therefore, the odds are a chess piece should be a separate class. A Pawn "is a" type of chess piece, so should probably be a subclass of the Chess Piece class. There are exceptions to these rules, but in my (limited) experience they are few and far between.
That's a simple and elegant way to look at it. I have never been aware of these rules of thumb, although I think I applied them intuitively. Thanks for the new insight.
Still, it doesn't fully capture all essential features of OO, like information hiding, encapsulation, dynamic binding and inheritance. Also, it doesn't logically entail the special kind of outsourcing that appears in many OO design patterns. Like in the case of moving the game piece: the piece evaluates whether the move is legal, and after that the board checks whether the move is possible and whether it would be a capture.
If you state encapsulation explicitly, the outsourcing will follow more directly: the piece is the right entity to determine whether a move (of itself) is legal, while the board is the right entity (has the right knowledge) to determine whether the move is possible and what would be its result.
the mishanator wrote:oh okay. i thought structs were just classes where everything was public though
In modern C++, this is true. Traditionally however, structs are just custom container types for heterogenous data. That's the reason why their members are public by default: usually you want to access the data directly. Classes, on the other hand, were invented specifically for OOP, and their members are private by default to promote information hiding. Therefore, it is recommended to use a class whenever the type will have its own behaviour or provide any form of data abstraction. Using structs as classes should be considered poor style.