Best OOP way to represent chess pieces

 

Consider a Chess application that has a Board containing an array of chess Piece s. Which of the following is the best object-oriented way of designing the Piece object, taking into account the advantages/disadvantages of each choice:

  • One class for all pieces, with a piece_type attribute that enum erates the types of chess pieces,
  • A Piece interface that all pieces inherit from, which would have the overhead of creating 6 other classes each corresponding to a unique chess piece.

    • The first option has the advantage of being lightweight and uses the fact that there is a lot of similar code involved with each chess piece, but is less "OOP". The second option defines an object for each chess piece, but would probably have to contain a lot of copied code and additional source files.

    Considering the above, which method would be the most "OOP" design for a chess Piece ?

    Definitely the second one. The reason is that different chess pieces aren't just different types, they have completely different behavior.

    So breaking it down into different classes allows you to specify correct movement (no two units move alike) and attack (eg pawn attacks diagonally) behavior for each piece nicely with polymorphism without having giant switch/case clauses in single class.

    As for copied code, that is definitely bad; if you find yourself in the need to copy code, it is best to move that particular code to separate class, however I'm not sure what would be needed to copy here - each piece is different.

    And as for additional source files, that is something you should almost never worry about. If you are getting lost in all the files it is best to organize it differently, eg putting all chess piece classes in their own folder.

    Update (from comment): The game should decide that the piece moves, but the piece decides how. So for example if you wanted to be provide feedback for the user, the user would click on a unit, and the game would ask the unit where it can move (because only the unit knows where it can move), and once the user would confirm the target, the game would tell the unit to move to the (valid!) target. So the game provides interaction between the pieces and user, but the pieces provide behavior particular to each piece.

    Indeed great answer, however, I would omit any " Definitely " from an answer, especially to OO related subjects...I assume that each time you address such a problem you'll reach a different design concept.

    IMO, there are several options, and any mix and match may work and be reasonably implemented. For instance, defining class "Movement" to stereotype the different moves a Piece can make. Different pieces can actually utilize same movement in certain game play.

    Interface vs. Base class definition, again, depending on whether you see any attributes to the classes or not. I see several (Type, assigned movement, Active/Inactive etc.) - and that actually shouts "Base Class"...

    For the actual game play, is there a "Player" class that actually instantiate "Moves"? just something to think about.

    链接地址: http://www.djcxy.com/p/51042.html

    上一篇: 棋盘和棋子之间相互依赖

    下一篇: 最好的OOP方式代表棋子