Когда прекратить наследование?

Однажды я задал вопрос о переполнении стека о наследовании.

Я сказал, что проектирую шахматный движок в ООП-моде. Таким образом, я наследую все свои части от абстрактного класса 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
        {

        }
    }
}

Теперь я вижу, что свойство 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утверждений выше. Единственным исключением может быть функция определения направления перемещения пешки по ее цвету, поскольку это характерно для пешек, но почти во всех других случаях вам не понадобится какой-либо специфичный для цвета код.

Другой интересный вопрос, если у вас действительно должны быть разные подклассы для разных видов пьес вообще. Это кажется мне разумным и естественным, поскольку правила для ходов для каждой фигуры различны, и вы наверняка можете реализовать это, используя разные перегруженные функции для каждой фигуры.

Конечно, можно было бы попытаться смоделировать это в более общем виде, путем разделения свойств деталей из их движущихся правил, но это может закончиться в абстрактном классе MovingRuleи иерархии подкласса MovingRulePawn, MovingRuleQueen... Я бы не начать его , что Кстати, так как это может легко привести к другой форме чрезмерного проектирования.

Наследование не так полезно, когда расширение не влияет на внешние возможности объекта .

Свойство Цвет не влияет , как объект Кусок используется . Например, все фигуры могут вызывать метод moveForward или moveBackwards (даже если перемещение не разрешено), но инкапсулированная логика пьесы использует свойство Color для определения абсолютного значения, которое представляет движение вперед или назад (-1 или + 1 по оси y), что касается вашего 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) {}
}

В этом ответе я предполагаю, что под «шахматным движком» автор вопроса подразумевает «шахматный ИИ», а не просто механизм проверки ходов.

Я думаю, что использование ООП для фигур и их правильных движений - плохая идея по двум причинам:

1. Сила шахматного движка во многом зависит от того, насколько быстро он может манипулировать досками, см., Например, представления шахматных программ . Учитывая уровень оптимизации, описанный в этой статье, я не думаю, что обычный вызов функции возможен. Вызов виртуального метода добавит уровень косвенности и приведет к еще большему снижению производительности. Стоимость ООП там недоступна.
2. Преимущества ООП, такие как расширяемость, бесполезны для фигур, так как шахматы вряд ли скоро получат новые фигуры. Жизнеспособная альтернатива иерархии типов на основе наследования включает использование перечислений и переключателей. Очень низкотехнологичный и C-подобный, но непревзойденный по производительности.

Отойти от соображений производительности, включая цвет фигуры в иерархии типов, на мой взгляд, плохая идея. Вы окажетесь в ситуациях, когда вам нужно проверить, имеют ли две части разные цвета, например, для захвата. Проверка этого условия легко выполняется с помощью свойства. Делать это, используя is WhitePiece-tests, было бы ужаснее по сравнению.

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

При этом, если вы пишете первый шахматный движок, я бы определенно посоветовал придерживаться принципов чистого программирования и избегать приемов оптимизации, описанных автором Crafty. Разобраться со спецификой шахматных правил (рокировка, повышение по службе, en-passant) и сложными техниками искусственного интеллекта (хеш-доски, вырезка альфа-бета) достаточно сложно.