Дизайн иерархии шахматных фигур: поля наследования и типов

Я бы пошел с иерархией классов.

Для поиска части вы можете вести отдельный список для каждого типа части. Так что вы знаете, где искать каждый тип части.

Для сравнения вы также можете полагаться на виртуальные методы.

Другой подход заключается в использовании компонентной архитектуры (как описано здесь: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/), но я думаю, что это слишком много для шахматной игры, где ты четко знаешь типы и знаешь, что эти типы не скоро изменятся :).

Как вариант, если ваш набор занятий ограничен - т.е. вы знаете количество, используйте вариант и посетителей. Например, boost::variant<king, queen, bishop, knight ...> И плата состоит из 2D-массива этого типа. Теперь для допроса можно использовать посетителей...

Я бы выбрал иерархию, и если я хочу знать тип (почему?), Имею виртуальный метод, который идентифицирует тип.

Я никогда не писал шахматную программу, но полагаю, что наиболее распространенными операциями будут такие вещи, как:

• показать / распечатать доску
• получить набор возможных ходов для каждой фигуры
• суммировать значения всех фигур на доске, возможно, суммировать некую «ценность позиции», которая зависит от фигуры (ладья на открытой линии и тому подобное)

Кроме того, у некоторых фигур есть «состояние» (король может рокироваться только в том случае, если он не ходил раньше, пешка может нанести мимолетный удар, если другая пешка только что переместилась на два поля), которое применимо только к одному типу фигур.

Все это кричит мне об иерархии классов. (Предполагая, что вам не нужна битовая производительность)

С другой стороны, маловероятно, что вам когда-либо придется добавлять новые типы фигур или что вы когда-либо сможете повторно использовать один из типов фигур отдельно. то есть расширяемость и модульность на самом деле не проблема. Поэтому, если вы обнаружите, что какая-то важная часть вашего алгоритма, которая действительно должна быть в одном месте, разбросана по нескольким классам частей, используйте оператор switch. Просто добавьте абстрактный метод класса Piece, который возвращает перечисление PieceType, и включите его.

Вы можете не беспокоиться о производительности и коде для удовольствия одновременно :)

Рассмотрите возможность использования «nibbleboard» (или, по крайней мере, byteboard) вместо битборда, где каждый nibbleboard представляет один тип фрагмента. Каждый фрагмент также является индексом в таблице одноэлементных объектов, которые работают с этим типом фрагмента.

class Empty : public Piece {};
class Rook : public Piece {};
...

const int wrook = 1;
...
const int bpawn = 12;

Piece* Operator[13] = {new Empty(), new Rook(), ..., new Pawn()};

byte table[64] = {
    wrook, wbishop, wknight, wking, wqueen, wknight, wbishop, wrook,
    wpawn, wpawn, wpawn, wpawn, wpawn, wpawn, wpawn, wpawn, 
    0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 
    bpawn, bpawn, bpawn, bpawn, bpawn, bpawn, bpawn, bpawn, 
    brook, bbishop, bknight, bking, bqueen, bknight, bbishop, brook};

// Given some position and some operation DoSomething we would have this:
Operator[table[position]]->DoSomething(table, position, <other parameters>);

// Possible return value of DoSomething might be new table

«Суперуродливый оператор switch» — это правильная техника. Это не уродливо. Это называется функциональным программированием.

Наследование — совершенно неправильный метод. Каждая из частей движется по-разному, имеет различную графику и другие свойства. Нет ничего общего. Шахматные фигуры не абстрактны. Это конкретный набор дискретных объектов.

Вы должны сделать что-то общее путем унификации: создать то, что называется типом суммы. В Окамле:

type shape = Pawn | Rook | Knight | Bishop | Queen | King
type color = Black | White
type piece = shape * color
type pos = { row:int;  col:int }

let check_white_move piece board from to = match piece with
| Pawn -> on_board to && (from.row = 2 && to.row = 4 or to.row = from.row + 1)
| ....

В С++ нет правильного типа суммы, вместо этого вы можете использовать:

enum shape { pawn, rook, knight, bishop, queen, king};
..
bool check_white_move (..) { switch piece {
 case pawn: ...

Это более неуклюже. Пожаловаться в комитеты C и C++. Но используйте правильную концепцию. Типы суммы (размеченные объединения, варианты) — это способ унифицировать дискретный набор конкретных типов. Классы и наследование используются для представления абстракций и их реализации.

В шахматах нет ничего абстрактного. Все дело в комбинациях. Это не вопрос преимуществ и недостатков различных техник: речь идет об использовании правильной техники.

[Кстати: да, вы можете попробовать вариант повышения, хотя я не могу рекомендовать его для этого приложения, так как части не имеют связанных данных, перечисление идеально]