什么时候停止继承？

很久以前，我在Stack Overflow上问了一个关于继承的问题。

我说过我以OOP方式设计国际象棋引擎。因此，我继承了Piece抽象类的所有片段，但继承仍然存在。让我按代码显示

public abstract class Piece
{
    public void MakeMove();
    public void TakeBackMove();
}

public abstract class Pawn: Piece {}

public class WhitePawn :Pawn {}

public class BlackPawn:Pawn {}

程序员发现我的设计超出了工程学，建议删除有色块类，并保留色块作为属性成员，如下所示。

public abstract class Piece
{
    public Color Color { get; set; }
    public abstract void MakeMove();
    public abstract void TakeBackMove();
}

这样，Piece可以知道他的颜色。实施后，我已经看到我的实施如下。

public abstract class Pawn: Piece
{
    public override void MakeMove()
    {
        if (this.Color == Color.White)
        {

        }
        else
        {

        }
    }

    public override void TakeBackMove()
    {
        if (this.Color == Color.White)
        {

        }
        else
        {

        }
    }
}

现在，我看到keep color属性导致实现中的if语句。这让我感到我们需要继承层次结构中的特定颜色块。

在这种情况下，您将拥有诸如WhitePawn，BlackPawn之类的类，还是会通过保留Color属性来进行设计？

没有看到这样的问题，您将如何开始设计？保留Color属性还是具有继承解决方案？

编辑：我想指定我的示例可能与现实生活中的示例不完全匹配。因此，在尝试猜测实现细节之前，只需集中问题。

我实际上只是问问使用Color属性是否会导致语句更好地使用继承？

假设您设计了一个包含车辆的应用程序。你创造这样的东西吗？

class BlackVehicle : Vehicle { }
class DarkBlueVehicle : Vehicle { }
class DarkGreenVehicle : Vehicle { }
// hundreds of other classes...

在现实生活中，颜色是对象（汽车或国际象棋）的一种属性，必须由一种属性表示。

是MakeMove与TakeBackMove黑人和白人不同？一点都不：规则对于两个玩家都是相同的，这意味着对于黑人和白人来说，这两种方法将完全相同，这意味着您要添加不需要的条件。

另一方面，如果您有WhitePawn和BlackPawn，那么您迟早会写下以下内容也不会令我感到惊讶：

var piece = (Pawn)this.CurrentPiece;
if (piece is WhitePawn)
{
}
else // The pice is of type BlackPawn
{
}

甚至类似：

public abstract class Pawn
{
    public Color Player
    {
        get
        {
            return this is WhitePawn ? Color.White : Color.Black;
        }
    }
}

// Now imagine doing the same thing for every other piece.

您应该问自己的是，为什么在Pawn类中确实需要这些语句：

    if (this.Color == Color.White)
    {

    }
    else
    {
    }

我很确定拥有一小部分功能就足够了

public abstract class Piece
{
    bool DoesPieceHaveSameColor(Piece otherPiece) { /*...*/   }

    Color OtherColor{get{/*...*/}}
    // ...
}

在您的Piece类中，并使用这些函数实现中的所有功能Pawn（以及的其他派生Piece），而无需执行if上述任何声明。唯一的例外可能是根据其颜色来确定Pawn的移动方向的功能，因为这是Pawn特有的，但是在几乎所有其他情况下，您都不需要任何颜色特定的代码。

另一个有趣的问题是，您是否真的应该为不同类型的片段提供不同的子类。对我来说，这似乎是合理且自然的，因为每个棋子的移动规则是不同的，并且您可以肯定地通过为每种棋子使用不同的重载函数来实现这一点。

当然，一个可以尝试在一个更通用的方法，来模拟这种来自他们的移动规则分离片的性能，但是这可能在抽象类中结束MovingRule和一个子类层次结构MovingRulePawn，MovingRuleQueen...我不会开始认为方式，因为它很容易导致另一种形式的过度工程。

当扩展不影响对象的外部功能时，继承没有用。

颜色属性不影响一片对象是如何使用的。例如，可以想象所有片段都可以调用moveForward或moveBackwards方法（即使该移动不合法），但是片段的封装逻辑使用Color属性确定代表向前或向后运动的绝对值（-1或+在“ y轴”上为1），就您的API而言，您的超类和子类是相同的对象（因为它们都公开了相同的方法）。

就个人而言，我将定义一些代表每种片段类型的常量，然后使用switch语句分支到私有方法中，这些私有方法返回“此”实例的可能动作。

就我个人而言，我根本不会继承任何东西Piece，因为我认为这样做不会让您有所收获。大概一块实际上并不关心它如何移动，只有哪一个正方形是其下一步移动的有效目的地。

也许您可以创建一个有效的移动计算器，该计算器可以了解某种类型的棋子可用的移动模式，并能够检索有效目标方块的列表，例如

interface IMoveCalculator
{
    List<Square> GetValidDestinations();
}

class KnightMoveCalculator : IMoveCalculator;
class QueenMoveCalculator : IMoveCalculator;
class PawnMoveCalculator : IMoveCalculator; 
// etc.

class Piece
{
    IMoveCalculator move_calculator;
public:
    Piece(IMoveCalculator mc) : move_calculator(mc) {}
}

在这个答案中，我假设问题的作者称“ chess engine”为“ chess AI”，而不仅仅是移动验证引擎。

我认为对零件及其有效运动使用OOP是一个坏主意，原因有两个：

1. 国际象棋引擎的强度在很大程度上取决于它能以多快的速度操纵棋盘，例如参见国际象棋程序棋盘表示法。考虑到本文描述的优化级别，我认为常规函数调用负担不起。调用虚拟方法将增加一个间接级别，并导致更高的性能损失。那里的OOP成本无法承受。
2. OOP的优点（例如可扩展性）对于棋子没有用，因为国际象棋不太可能很快获得新棋子。对于基于继承的类型层次结构，可行的替代方法包括使用枚举和切换。科技含量很低，类似C，但是在性能方面却难以超越。

在我看来，放弃性能方面的考虑，包括类型层次结构中部件的颜色，是一个坏主意。您会发现自己需要检查两块是否具有不同的颜色（例如用于捕获）。使用属性可以很容易地检查此条件。is WhitePiece相比之下，使用-tests进行比较麻烦。

还有另一个实际原因，需要避免将移动生成转移到特定于片段的方法，即，不同的片段共享共同的移动，例如，车子和皇后。为了避免重复代码，您将必须将通用代码分解为基本方法，并进行另一个昂贵的调用。

话虽如此，如果这是您正在编写的第一个国际象棋引擎，我绝对建议您采用简洁的编程原则，并避免使用Crafty作者描述的优化技巧。处理国际象棋规则（铸造，晋升，传球）和复杂的AI技术（哈希板，alpha-beta剪切）的细节具有挑战性。