상속을 언제 중단해야합니까?

옛날 옛적에 나는 상속에 대해 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();
}

이런 식으로 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
        {

        }
    }
}

이제 구현에서 if 문을 유발하는 색상 속성을 유지하는 것을 볼 수 있습니다. 상속 계층 구조에서 특정 색상 조각이 필요하다고 생각합니다.

이 경우 WhitePawn, BlackPawn과 같은 클래스가 있습니까? 아니면 Color 속성을 유지하여 디자인을 하시겠습니까?

그런 문제를 보지 않으면 어떻게 디자인을 시작하고 싶습니까? 색상 속성을 유지하거나 상속 솔루션이 있습니까?

편집 : 내 예제가 실제 예제와 완전히 일치하지 않도록 지정하고 싶습니다. 따라서 구현 세부 정보를 추측하기 전에 질문에 집중하십시오.

실제로 Color 속성을 사용하면 if 문이 상속을 더 잘 사용할 수 있는지 묻습니다.

차량이 포함 된 응용 프로그램을 설계한다고 가정하십시오. 이런 식으로 만들었습니까?

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. 폰에 따라 폰의 이동 방향을 결정하는 기능은 예외 일 수 있습니다. 폰에 따라 다르기 때문에 거의 모든 경우에 색별 코드가 필요하지 않습니다.

다른 흥미로운 질문은 다른 종류의 조각에 대해 다른 서브 클래스를 실제로 가지고 있어야하는지입니다. 각 조각의 이동 규칙이 다르기 때문에 합리적이고 자연스럽게 보입니다. 각 종류의 조각에 대해 서로 다른 오버로드 함수를 사용하여이를 구현할 수 있습니다.

물론, 하나는 자신의 이동 규칙에서 조각의 속성을 분리하여,보다 일반적인 방법으로이 모델을 시도 할 수 있지만,이 추상 클래스에 끝날 수 MovingRule와 서브 클래스 계층 구조 MovingRulePawn, MovingRuleQueen... 나는 그것을 시작할 것이라고 다른 형태의 오버 엔지니어링으로 쉽게 이어질 수 있기 때문입니다.

상속이 개체의 외부 기능에 영향을 미치지 않는 경우 상속은 유용하지 않습니다 .

Color 속성은 Piece 개체 사용 방법에 영향을 미치지 않습니다 . 예를 들어, 모든 조각은 이동이 합법적이지 않은 경우에도 moveForward 또는 moveBackwards 메서드를 호출 할 수 있지만 조각의 캡슐화 된 논리는 Color 속성을 사용하여 앞으로 또는 뒤로 이동을 나타내는 절대 값을 결정합니다 (-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를 사용하는 것이 두 가지 이유로 나쁜 생각이라고 생각합니다.

1. 체스 엔진의 강점은 보드를 얼마나 빠르게 조작 할 수 있는지에 따라 크게 달라집니다 (예 : 체스 프로그램 보드 표현 참조) . 이 기사에서 설명하는 최적화 수준을 고려할 때 정규 함수 호출이 저렴하다고 생각하지 않습니다. 가상 메서드를 호출하면 간접적 인 수준이 추가되고 성능이 저하 될 수 있습니다. OOP 비용은 저렴하지 않습니다.
2. 체스는 곧 새로운 조각을 얻을 수 없기 때문에 확장 성과 같은 OOP의 이점은 조각에 사용되지 않습니다. 상속 기반 형식 계층의 대안으로 열거 형과 스위치를 사용할 수 있습니다. 기술 수준이 낮고 C와 비슷하지만 성능 측면에서는 이길 수 없습니다.

유형 계층 구조에서 조각의 색상을 포함하여 성능 고려 사항에서 벗어나는 것은 나쁜 생각입니다. 캡처와 같이 두 조각의 색상이 다른지 확인해야하는 상황에 처할 수 있습니다. 이 조건을 확인하는 것은 속성을 사용하여 쉽게 수행 할 수 있습니다. is WhitePiece-tests를 사용하면 비교가 더 어려워집니다.

이동 동작 생성을 조각 특정 방법으로 피하는 또 다른 실질적인 이유가 있습니다. 즉, 다른 조각이 공통 동작 (예 : 루크 및 여왕)을 공유하기 때문입니다. 중복 코드를 피하려면 공통 코드를 기본 메소드로 인수 분해해야하며 비용이 많이 드는 또 다른 호출이 필요합니다.

즉, 처음 작성하는 체스 엔진이라면 깨끗한 프로그래밍 원칙을 따르고 Crafty의 저자가 설명 한 최적화 트릭을 피하는 것이 좋습니다. 체스 규칙 (캐스팅, 판촉, 난폭 한)과 복잡한 AI 기술 (해시 보드, 알파-베타 컷)의 세부 사항을 다루는 것은 충분히 어려운 일입니다.