吸气剂是否违反得墨忒耳定律？

Question

想象有一个GameState 类型使用GameContext（通过process 方法）：

abstract class GameState {
    public abstract void process(GameContext context);
}

GameContext 将包含诸如 Player、Shops 等对游戏至关重要的东西。

一个状态可以访问它需要的东西：

class CombatState extends GameState {
    public void process(GameContext context) {
        Player player = context.getPlayer();

        if(player.isAlive()) {
            //...
        }
    }
}

语句player.isAlive() 可以重写为context.getPlayer().isAlive()。

我的问题

得墨忒耳法则规定对象只能与直系亲属互动。这是否违反了原则，如何解决？

对于要动态处理的每个状态，所有可能的状态都必须接受形式参数。 这使得严格传递对象所需的内容变得困难，这就是每个状态从“主要来源”获取所需内容的原因。我觉得主要来源的凝聚力很低，因为ShopState 需要的数据与CombatState 不同

Answer 1

状态不是进程，进程是进程。战斗是一个过程，活着是一个状态。

使用process 的抽象名称会让你需要打破得墨忒耳定律。

看这个例子：

class CombatProcess extends GameProcess {
    public void hit(Player puncher, Player beaten) {
        if (beaten.getState().isAlive()) {
           Weapon oneWeapon = one.getCurrentWeapon();
               ...
        }
    }
}

CombatProcess 中的一切都尽可能具体。

分析哪个玩家与哪个玩家战斗不是 CombatProcess 本身的责任！在 CombatProcess 开始之前，您必须知道与谁作战。

编辑：

在你写的这个答案的 cmets 中：

如果我在 Set、List 或 Map 中有状态，我将无法多态地处理这些状态，

这是绝对正确的。 Hook/Anchor-Pattern 是从 1996 年开始的，并且仍然在 Windows 中广泛使用和荣耀（所谓的 system-hooks）。不幸的是，由于一些批评，它没有进入 OOD 的前 10 种模式。其中一位批评者是：

...把一个进程的所有操作抽象成逻辑独立的钩子，然后锚定它们并适当地迭代它们并不容易。

我个人的看法是，Hook/Ancher-Pattern 在 1996 年是革命性的，未来与 CDI（例如 spring）的结合将是革命性的。

终于！你可以决定：

1. 打破得墨忒耳法则。
2. 放下钩子/锚模式。
3. 写一个解决方法，描述here。

Answer 2

由于定界符定律是松散耦合的一个特殊情况。

我认为它的工作方式是：

即使我们链接了多个方法（比如），我们也可以访问特定类的字段及其方法。我们在java中一直这样做，需要注意的是，链接仅适用于单个类的方法。

分隔符法则告诫我们不要同时访问多个类的对象和/或方法。

例子：

如果我们有 A、B、C 类。

B 类有一个字段持有 A 的引用，C 有 B 的引用。

那么我们不应该使用 getter 来获取 A 到 C 的引用，它有助于维护松散耦合。

再说一次，这就是我认为它的工作方式。