考虑一个Chess应用程序，其Board包含一个国际象棋Piece数组。考虑到每种选择的优点/缺点，以下哪一项是设计Piece对象的最佳面向对象方式：
piece_type属性enum可以减少国际象棋的类型，Piece 接口，所有部分都从继承，这将产生创建6个其他类的开销，每个类对应一个独特的棋子。第一种选择具有轻量级的优点，并且使用每个棋子涉及许多类似代码的事实，但不是“OOP”。第二个选项为每个棋子定义一个对象，但可能必须包含大量复制的代码和其他源文件。
考虑到上述情况，哪种方法是国际象棋Piece的最“OOP”设计？
答案 0 :(得分：4)
绝对是第二个。原因是不同的棋子不仅仅是不同的类型，它们的行为完全不同。
因此将其分解为不同的类允许您指定正确的移动（没有两个单位移动相似）和攻击（例如对角线的典当攻击）行为，对于每个部分很好地使用多态，而不需要单个类中的巨型switch / case子句。 / p>
至于复制的代码，这绝对是坏的;如果您发现自己需要复制代码，最好将该特定代码移到单独的类中，但是我不确定在这里复制需要什么 - 每个部分都不同。
至于其他源文件，这是你几乎不用担心的事情。如果您迷失在所有文件中，最好以不同方式组织它，例如将所有棋子类放在他们自己的文件夹中。
更新（来自评论）： 游戏应该决定作品的移动，但作品决定如何。因此，例如，如果您想要为用户提供反馈，则用户将点击一个单元，游戏将询问该单元可以移动的位置（因为只有该单元知道它可以移动的位置），并且一旦用户愿意确认目标，游戏会告诉单位移动到（有效！）目标。因此，游戏提供了作品和用户之间的互动，但这些作品提供了特定于每件作品的行为。
答案 1 :(得分：-2)
确实很好的回答，但是，我会省略任何＆＃34; 绝对＆＃34;从一个答案，特别是与OO相关的主题......我假设每次你解决这个问题，你都会达到不同的设计理念。
IMO，有几种选择，任何混合和匹配都可以起作用并合理实施。例如，定义类＆＃34;运动＆＃34;刻板印象一件作品可以制作的不同动作。在某些游戏中，不同的棋子实际上可以使用相同的动作。
接口与基类定义，同样取决于您是否看到类的任何属性。我看到了几个（类型，指定的移动，活动/非活动等） - 并且实际上是在呼喊＆＃34;基础类＆＃34; ...
对于实际的游戏，是否有＃34;播放器＆＃34;实际实例化的类＃34;移动＆＃34;？只是想一想。