考虑一个具有包含国际象棋Piece s数组的Board的国际象棋应用程序。考虑到每种选择的优缺点，以下哪种是设计Piece对象的最佳面向对象方法：
-
所有棋子的一个类，具有
piece_type属性，enum表示棋子的类型 -
所有棋子都继承自的
Piece接口，这将产生创建6个其他类的开销，每个类对应一个唯一的棋子
第一个选项的优点是轻量级，并且使用了这样一个事实，即每个棋子都有很多类似的代码，但较少"OOP"。第二个选项为每个棋子定义一个对象，但可能必须包含大量复制的代码和额外的源文件。
考虑到以上情况，哪种方法是国际象棋Piece最"OOP"的设计？
肯定是第二个。原因是不同的棋子不仅仅是不同的类型，它们有完全不同的行为。
因此，将其分解为不同的类可以让你很好地使用多态性为每一块指定正确的移动（没有两个单位移动相同）和攻击（例如典当对角攻击）行为，而不需要在单个类中使用巨大的switch/case子句。
至于复制的代码，那肯定是不好的；如果您发现自己需要复制代码，最好将特定的代码移动到单独的类中，但是我不确定在这里复制需要什么——每一部分都是不同的。
至于额外的源文件，这是你几乎永远不应该担心的事情。如果你迷失在所有的文件中，最好以不同的方式组织它，例如将所有棋子类放在自己的文件夹中。
更新（来自评论）：游戏应该决定棋子移动，但棋子决定如何移动。例如，如果你想为用户提供反馈，用户会点击一个单元，游戏会询问该单元可以移动到哪里（因为只有该单元知道它可以移动到什么地方），一旦用户确认了目标，游戏就会告诉该单元移动到（有效！）目标。因此，游戏提供了棋子和用户之间的交互，但棋子提供了每个棋子特有的行为。
的确是个不错的答案，但我会在答案中省略任何"绝对"，尤其是对OO相关主题。。。我认为，每次你解决这样的问题，你都会得出不同的设计概念。
国际海事组织，有几种选择，任何混合搭配都可能奏效，并得到合理实施。例如，定义类"Movement"来定型Piece可以做出的不同动作。在某些游戏中，不同的棋子实际上可以使用相同的动作。
接口与基类的定义，同样取决于您是否看到类的任何属性。我看到了几个（类型、指定的移动、活动/非活动等）——这实际上是在喊"基类"。。。
对于实际的游戏，是否有一个"玩家"类可以实例化"移动"？只是一些值得思考的事情。