delphi - 如何避免循环单位引用？

Question

想象一下以下两类国际象棋游戏:

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

TChessPiece = class abstract
public
   procedure GetMoveTargets (BoardPos : TPoint; Board : TChessBoard; MoveTargetList : TList <TPoint>);
...
end;

我希望在两个独立的单元 ChessBoard.pas 和 ChessPiece.pas 中定义这两个类。

如何避免我在这里遇到的循环单元引用(每个单元都需要在另一个单元的接口(interface)部分)？

Answer 1

Delphi 单元并没有“从根本上崩溃”。它们的工作方式促进了编译器的惊人速度并促进了干净的类设计。

能够以 Prims/.NET 允许的方式将类分布在单元上是一种可以说从根本上被打破的方法，因为它通过允许开发人员忽略正确设计他们的框架的需要来促进类的困惑组织，促进强加任意代码结构规则，例如“每单元一个类”，作为通用格言没有技术或组织值(value)。

在这种情况下，我立即注意到这种循环引用困境引起的类设计的特殊性。

也就是说，为什么一件作品需要引用板？

如果一块棋子是从棋盘上取下来的，那么这样的引用就没有意义了，或者被移除棋子的有效“移动目标”可能只是那些对于该棋子在新游戏中作为“起始位置”有效的棋子？但是我认为这除了为要求 GetMoveTargets 支持使用 NIL 板引用进行调用的情况的任意理由之外没有任何意义。

在任何给定时间，单个作品的特定位置是个人的属性(property)游戏国际象棋，同样，任何给定棋子可能的有效移动取决于游戏中其他棋子的位置。

TChessPiece.GetMoveTargets 不需要了解当前游戏状态。这是 TChessGame 的责任。并且 TChessPiece 不需要对游戏或棋盘的引用来确定从给定当前位置开始的有效移动目标。板约束(8 个等级和文件)是域常量，而不是给定板实例的属性。

因此，需要一个 TChessGame 来封装知识，这些知识结合了棋盘、棋子和 - 至关重要的 - 规则的意识，但棋盘和棋子不需要彼此或游戏的知识。

将与不同棋子相关的规则放在棋子类型本身的类中似乎很诱人，但恕我直言，这是一个错误，因为许多规则基于与其他棋子的交互，并且在某些情况下基于特定棋子类型。这种“大局”行为需要对整个游戏状态进行一定程度的监督(阅读:概述)，这在特定棋子类别中是不合适的。

例如如果这些对角方格中的任何一个被占用，TChessPawn 可以确定有效的移动目标是向前一或两个方格或对角向前一方格。但是，如果棋子的移动使国王处于 CHECK 状态，则棋子根本无法移动。

我将通过简单地允许 pawn 类指示所有可能的移动目标来解决这个问题 - 向前 1 或 2 个方格以及两个对角向前方格。 TChessGame 然后通过引用这些移动目标的占用率和游戏状态来确定哪些是有效的。只有当兵在它的本垒上时，向前 2 个方格才有可能，向前方格被占用阻止移动 = 无效目标，未占用的对角线方格促进移动，如果任何其他有效移动暴露了国王，那么该移动也是无效的。

同样，将普遍适用的规则放在基础 中可能是一种诱惑。 TChessPiece 类(例如，给定的移动是否暴露了国王？)，但应用该规则需要了解整体游戏状态 - 即其他棋子的放置 - 所以它更适合作为 的一般行为属于TChessGame 类，恕我直言

除了移动目标之外，棋子还需要指示 CaptureTargets，这在大多数棋子的情况下是相同的，但在某些情况下却大不相同 - pawn 就是一个很好的例子。但是同样，对于任何给定的移动，所有潜在捕获中的哪一个 - 如果有的话 - 是 - 恕我直言 - 对游戏规则的评估，而不是棋子或棋子类别的行为。

与 99% 的这种情况 (ime - ymmv) 的情况一样，通过更改类设计以更好地表示正在建模的问题，而不是找到一种将类设计硬塞到任意文件组织中的方法，或许可以更好地解决困境。