Коли припинити спадщину?

Колись тому я задав запитання на стек 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();
}

Таким чином П'єс може пізнати його колір. Після впровадження я бачив, як моя реалізація йде як нижче.

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
        {

        }
    }
}

Тепер я бачу, що збереження властивості кольору викликає, якщо заяви у реалізаціях. Від цього я відчуваю, що нам потрібні конкретні кольорові фігури в ієрархії спадкування.

У такому випадку ви мали б такі класи, як 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.

Що ви повинні запитати у себе, це чому вам справді потрібні ці твердження у вашому класі пішаків:

    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 (навіть якщо переміщення не є законним), але інкапсульована логіка Piece використовує властивість Color для визначення абсолютного значення, яке представляє рух вперед або назад (-1 або + 1 на "вісі"), що стосується вашого API, ваш суперклас та підкласи - це однакові об'єкти (оскільки всі вони піддають однакові методи).

Особисто я б визначив деякі константи, які представляють кожен тип фрагмента, а потім використовувати оператор перемикання, щоб розгалужувати приватні методи, які повертають можливі ходи для "цього" екземпляра.

Особисто я взагалі нічого не успадкував би 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 (хеширование дощок, альфа-бета-вирізання) є досить складним завданням.