Как избежать круговой ссылки на единицу измерения?

Измените модуль, который определяет TChessPiece, чтобы он выглядел следующим образом:

TYPE
  tBaseChessBoard = class;

  TChessPiece = class
    procedure GetMoveTargets (BoardPos : TPoint; Board : TBaseChessBoard; ...    
  ...
  end;    

затем измените модуль, который определяет TChessBoard, чтобы он выглядел следующим образом:

USES
  unit_containing_tBaseChessboard;

TYPE
  TChessBoard = class(tBaseChessBoard)
  private
    FBoard : array [1..8, 1..8] of TChessPiece;
  ...
  end;  

Это позволяет вам передавать конкретные экземпляры шахматной фигуре, не беспокоясь о циклической ссылке. Поскольку доска использует Tchesspieces в своем частном порядке, она действительно не должна существовать до объявления Tchesspiece, просто как заполнитель. Любые переменные состояния, о которых должен знать tChessPiece, конечно, должны быть помещены в tBaseChessBoard, где они будут доступны обоим.

Модули Delphi не "принципиально сломаны". То, как они работают, способствует феноменальной скорости компилятора и способствует чистому дизайну классов.

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

В этом случае я сразу же заметил идиосинкразию в дизайне классов, возникающую из-за этой дилеммы круговых ссылок.

То есть, зачем элементу когда-либо нужна ссылка на доску?

Если фигура взята с доски, такая ссылка не имеет смысла, или, возможно, действительные «цели перемещения» для удаленной фигуры действительны только для этой фигуры в качестве «стартовой позиции» в новой игре? Но я не думаю, что это имеет смысл как нечто иное, как произвольное обоснование случая, требующего, чтобы GetMoveTargets поддерживал вызов с нулевой ссылкой на правление.

Конкретное размещение отдельной фигуры в любой момент времени является свойством отдельной игры в шахматы, а также ДЕЙСТВИТЕЛЬНЫМИ ходами, которые могут быть ВОЗМОЖНЫМИ для любой данной фигуры зависят от размещения ДРУГИХ фигур в игре.

TChessPiece.GetMoveTargets не требует сведений о текущем состоянии игры. За это отвечает TChessGame. И TChessPiece не нуждается в ссылке на игру или на доску, чтобы определить действительные цели хода из заданной текущей позиции. Ограничения доски (8 рангов и файлов) являются константами домена, а не свойствами данного экземпляра доски.

Таким образом, требуется TChessGame, инкапсулирующая знания, которые сочетают в себе понимание доски, фигур и, что особенно важно, правил, но доске и фигурам не нужны знания друг о друге ИЛИ об игре. .

Может показаться заманчивым поместить правила, относящиеся к разным фигурам, в класс для самого типа фигуры, но имхо это ошибка, поскольку многие правила основаны на взаимодействии с другими фигурами, а в некоторых случаях и с конкретными типами фигур. Такое поведение «в целом» требует определенного контроля (читай: обзора) общего состояния игры, что не подходит для определенного класса фигур.

например TChessPawn может определить, что допустимой целью хода является одна или две клетки вперед или одна клетка по диагонали вперед, если любая из этих диагональных клеток занята. Однако, если движение пешки ставит короля в положение ШАХ, то пешка вообще не может двигаться.

Я бы подошел к этому, просто позволив классу пешки указать все ВОЗМОЖНЫЕ цели хода - на 1 или 2 поля вперед и на оба поля по диагонали вперед. Затем TChessGame определяет, какие из них являются допустимыми, исходя из занятости этих целей перемещения и состояния игры. 2 поля вперед возможны только в том случае, если пешка находится на своей исходной горизонтали, занятые поля вперед БЛОКИРУЮТ ход = недопустимая цель, незанятые диагональные клетки ОБЛЕГЧАЮТ ход, и если любой другой допустимый ход обнажает короля, то этот ход также недействителен.

Опять же, может возникнуть искушение поместить общеприменимые правила в базовый класс TChessPiece (например, раскрывает ли данный ход короля?), но применение этого правила требует понимания общего состояния игры, т.е. других фигур - так что это более правильно относится к обобщенному поведению класса TChessGame, imho

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

Как и в случае с 99% таких ситуаций (ime - ymmv), дилемма, возможно, лучше решается путем изменения дизайна класса, чтобы лучше представить моделируемую проблему, а не путем поиска способа впихнуть дизайн класса в произвольную файловую организацию.