継承を停止するのはいつですか？

むかしむかし、継承についてStack Overflowで質問しました。

私はチェスエンジンをOOPファッションで設計すると言った。だから私はピースの抽象クラスからすべてのピースを継承しますが、継承はまだ続きます。コードで表示させてください

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();
}

このようにして、ピースは彼の色を知ることができます。実装後、実装が次のようになることを確認しました。

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
        {

        }
    }
}

今度は、色のプロパティが原因でifステートメントが実装されていることがわかります。継承階層に特定のカラーピースが必要だと感じます。

そのような場合、WhitePawn、BlackPawnのようなクラスを持っているでしょうか、それともColorプロパティを保持してデザインに行きますか？

このような問題がなければ、どのように設計を開始したいですか？Colorプロパティを保持するか、継承ソリューションを持っていますか？

編集：私の例が実際の例と完全に一致しない可能性があることを指定したいと思います。したがって、実装の詳細を推測する前に、問題に集中してください。

Colorプロパティを使用すると、ifステートメントで継承を使用した方がよいかどうかを確認するだけです。

車両を含むアプリケーションを設計するとします。このようなものを作成しますか？

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

現実には、色はオブジェクト（車またはチェスの駒）のプロパティであり、プロパティで表す必要があります。

あるMakeMoveとTakeBackMove黒人と白人のために違うのですか？まったく違います：ルールは両方のプレーヤーで同じです。つまり、これらの2つの方法は黒と白でまったく同じです。つまり、不要な条件を追加しています。

一方、あなたがWhitePawnand を持っている場合、遅かれ早かれあなたが書いても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他の派生物のすべての関数を実装します。これはポーンに固有であるため、ポーンの移動方向をその色で決定する関数は例外である場合がありますが、他のほとんどすべての場合、色固有のコードは必要ありません。Pieceif

もう1つの興味深い問題は、実際には、さまざまな種類のピースに対してさまざまなサブクラスを用意する必要があるかどうかです。各ピースの移動のルールは異なり、ピースの種類ごとに異なるオーバーロード関数を使用することでこれを確実に実装できるので、それは私には合理的で自然なようです。

もちろん、ピースのプロパティを移動ルールから分離することにより、これをより一般的な方法でモデル化しようとすることもできますが、これは、抽象クラスMovingRuleとサブクラス階層MovingRulePawnで終わる可能性がありMovingRuleQueenます...なぜなら、それは簡単に別の形のオーバーエンジニアリングにつながる可能性があるからです。

拡張機能がオブジェクトの外部機能に影響を与えない場合、継承はそれほど役に立ちません。

Colorプロパティは、Pieceオブジェクトの使用方法には影響しません。たとえば、すべてのピースはおそらくmoveForwardまたはmoveBackwardsメソッドを呼び出すことができますが（移動が正当でない場合でも）、Pieceのカプセル化されたロジックはColorプロパティを使用して、前方または後方への移動を表す絶対値を決定します（-1または+ 「y軸」の1）、APIに関する限り、スーパークラスとサブクラスは同一のオブジェクトです（すべて同じメソッドを公開しているため）。

個人的には、各ピースタイプを表す定数をいくつか定義してから、switchステートメントを使用して、「this」インスタンスの可能な移動を返すプライベートメソッドに分岐します。

個人的には何も受け継がないだろう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) {}
}

この回答では、質問の作成者が「チェスエンジン」とは、単なる移動検証エンジンではなく、「チェスAI」を意味すると想定しています。

作品とその有効な動きにOOPを使用することは、2つの理由から悪い考えだと思います。

1. チェスエンジンの強さは、ボードの操作速度に大きく依存します。たとえば、チェスプログラムボードの表現を参照してください。この記事で説明する最適化のレベルを考えると、通常の関数呼び出しは手頃な価格ではないと思います。仮想メソッドを呼び出すと、間接的なレベルが追加され、さらに高いパフォーマンスのペナルティが発生します。OOPのコストは手頃ではありません。
2. 拡張性などのOOPの利点は、チェスがすぐに新しいピースを取得する可能性が低いため、ピースには役に立ちません。継承ベースの型階層の実行可能な代替策には、列挙型とスイッチの使用が含まれます。非常にローテクでCライクですが、パフォーマンスの面では勝てません。

タイプ階層のピースの色など、パフォーマンスの考慮事項から離れることは、私の考えでは悪い考えです。たとえば、キャプチャのために、2つのピースの色が異なるかどうかを確認する必要がある場合があります。この条件の確認は、プロパティを使用して簡単に実行できます。is WhitePiece-testsを使用してそれを行うことは、比較すると醜いでしょう。

ムーブの生成をピース固有のメソッドに移動することを回避する別の実用的な理由もあります。つまり、ルークとクイーンなど、異なるピースが共通のムーブを共有しているためです。重複するコードを回避するには、共通コードを基本メソッドに因数分解し、さらに別のコストのかかる呼び出しを行う必要があります。

そうは言っても、それがあなたが書いている最初のチェスエンジンである場合、私は間違いなく、クリーンなプログラミング原則を採用し、Craftyの作者が説明した最適化のトリックを避けることをお勧めします。チェスのルール（キャスティング、プロモーション、エンパッサン）と複雑なAIテクニック（ハッシングボード、アルファ-ベータカット）に対処することは十分に困難です。