规避巫师和战士中的规则

在这一系列博客文章中，Eric Lippert使用向导和战士作为示例描述了面向对象设计中的问题，其中：

abstract class Weapon { }
sealed class Staff : Weapon { }
sealed class Sword : Weapon { }

abstract class Player 
{ 
  public Weapon Weapon { get; set; }
}
sealed class Wizard : Player { }
sealed class Warrior : Player { }

然后添加一些规则：

• 战士只能使用剑。
• 向导只能使用人员。

然后，他继续演示如果您尝试使用C＃类型系统强制执行这些规则（例如，让Wizard类负责确保向导只能使用人员）会遇到的问题。您违反了Liskov替代原则，冒着运行时异常的危险，或者最终遇到了难以扩展的代码。

他提出的解决方案是Player类不进行任何验证。它仅用于跟踪状态。然后，不要通过以下方式为玩家提供武器：

player.Weapon = new Sword();

状态由Commands并根据Rules 修改：

...我们制作了一个Command名为的Wield对象，它带有两个游戏状态对象a Player和a Weapon。当用户向系统发出命令“此向导应使用那把剑”时，该命令将在一组Rules 的上下文中进行评估，这会产生一系列Effects。我们有一个Rule说，当玩家尝试挥舞一种武器时，其效果是丢弃了现有武器（如果有的话），而新武器成为了玩家的武器。我们还有另一条规则增强了第一条规则，即当向导尝试挥舞剑时，第一条规则的效果不适用。

我原则上喜欢这个想法，但对如何在实践中使用它有所关注。

似乎没有什么可以通过简单地将on 设置为来阻止开发人员规避Commandsand Rule的。该属性需要可通过命令访问，因此无法进行设置。WeaponPlayerWeaponWieldprivate set

那么，是什么呢防止开发人员这样做呢？他们只需要记住不要吗？

博客文章系列引发的整个争论在第五部分：

我们没有理由相信C＃类型系统的设计具有足够的通用性，可以对《龙与地下城》的规则进行编码，那么我们为什么还要尝试呢？

我们已经解决了“表示系统规则的代码在哪里？”的问题。它进入代表系统规则的对象，而不进入代表游戏状态的对象；状态对象的关注点在于保持其状态的一致性，而不是评估游戏规则。

武器，角色，怪物和其他游戏对象概不负责检查其可以做什么或不能做什么。规则系统对此负责。该Command对象也没有对游戏对象执行任何操作。它只是代表对他们做某事的尝试。然后，规则系统检查命令是否可行，以及何时是规则系统通过在游戏对象上调用适当的方法来执行命令。

如果开发人员想要创建第二个规则系统，该第二个规则系统使用第一个规则系统不允许的角色和武器来做事，那么他们可以这样做，因为在C＃中，您（没有讨厌的反射黑客）无法找出方法调用的来源从。

在某些情况下可能可行的解决方法是将游戏对象（或它们的接口）与规则引擎一起放在一个程序集中，并将任何更改方法标记为。任何需要只读访问游戏对象的系统都将位于不同的程序集中，这意味着它们将只能访问方法。这仍然留下了游戏对象相互调用内部方法的漏洞。但是这样做会产生明显的代码味道，因为您同意游戏对象类应该是愚蠢的状态持有者。internalpublic

原始代码的明显问题是它正在执行数据建模而不是对象建模。请注意，在链接的文章中绝对没有提及实际的业务需求！

我将从尝试获得实际的功能要求开始。例如：“任何玩家都可以攻击其他任何玩家，...”。这里：

interface Player {
    void Attack(Player enemy);
}

“玩家可以使用攻击中使用的武器，奇才可以使用法杖，战士使用剑”：

public class Wizard: Player {
    ...
    public void Wield(Staff weapon) { ... }
    ...
}
public class Warrior: Player {
    ...
    public void Wield(Sword sword) { ... }
    ...
}

“每种武器都对被攻击的敌人造成伤害”。好的，现在我们必须有一个用于武器的通用接口：

interface Weapon {
    void dealDamageTo(Player enemy);
}

等等...为什么没有Wield()在Player？因为没有要求任何玩家都可以使用任何武器。

我可以想象，有一个要求说：“任何人都Player可以尝试挥舞任何东西Weapon。” 但是，这将是完全不同的事情。我可能会这样建模：

interface Player {
    void Attack(Player enemy);
    void TryWielding(Weapon weapon); // Throws UnwieldableException
}

摘要：仅对需求进行建模。不要做数据建模，那不是oo建模。

一种方法是将Wield命令传递给Player。然后，播放器执行Wield命令，该命令检查适当的规则并返回Weapon，Player然后使用设置其自己的“武器”字段。这样，“武器”字段可以有一个私人设置器，并且只能通过将Wield命令传递给玩家来设置。

没有什么可以阻止开发人员这样做的。实际上，埃里克·利珀特（Eric Lippert）尝试了许多不同的技术，但是它们都有缺点。那是该系列文章的全部重点，要阻止开发人员这样做并不容易，而且他尝试的一切都有缺点。最后，他决定将Command对象与规则结合使用是可行的方法。

使用规则，您可以将a的Weapon属性设置为a Wizard，Sword但是当您要求Wizard挥舞武器（Sword）并进行攻击时，它将没有任何效果，因此不会更改任何状态。正如他在下面说的：

我们还有另一条规则增强了第一条规则，即当向导尝试挥舞剑时，第一条规则的效果不适用。这种情况的影响是“发出令人难忘的长号声音，用户此回合失去动作，没有游戏状态发生变化

换句话说，我们不能通过type关系来执行这样的规则，他尝试了许多不同的方式，但是要么不喜欢它，要么不起作用。因此，他说我们唯一能做的就是在运行时对其进行处理。抛出异常是不好的，因为他不认为这是异常。

他最终选择了上述解决方案。该解决方案基本上说您可以设置任何武器，但是当您放弃它时，如果不是正确的武器，则基本上是无用的。但是不会抛出异常。

我认为这是一个很好的解决方案。尽管在某些情况下，我也会使用try-set模式。

作者的第一个废弃解决方案是用类型系统表示规则。类型系统在编译时进行评估。如果将规则从类型系统中分离出来，则编译器将不再检查它们，因此没有什么可以阻止开发人员本身犯错误。

但是，编译器没有检查的每一个逻辑/建模都面临着这个问题，对此的一般回答是（单元）测试。因此，作者提出的解决方案需要强大的测试工具来规避开发人员的错误。为了强调需要强大的测试工具来处理只能在运行时检测到的错误的观点，请参阅Bruce Eckel的这篇文章，该文章提出了一个论点，即您需要将强类型转换为动态语言中的更强测试。

总之，可以防止开发人员犯错误的唯一事情是进行一组（单元）测试，检查所有规则是否得到遵守。

我可能在这里错过了一些微妙之处，但是我不确定问题出在类型系统上。也许这是C＃中的约定。

例如，您可以通过在中Weapon保护setter 来使此完全类型安全Player。然后加setSword(Sword)和setStaff(Staff)，以Warrior和Wizard分别是通话的保护制定者。

这样，Player/ Weapon关系就会被静态检查，而无关紧要的代码只能使用a Player来获取Weapon。

那么，是什么阻止了开发人员这样做呢？他们只需要记住不要吗？

这个问题与称为“ 验证位置 ”的相当神圣的话题实际上是相同的（很可能也注意到了ddd）。

因此，在回答这个问题之前，您应该问自己：要遵循的规则的本质是什么？它们是用石头雕刻并定义实体吗？违反这些规则是否会导致实体不再是实体？如果是，除了将这些规则保留在命令验证中外，还将它们放在一个实体中。因此，如果开发人员忘记了验证命令，则您的实体将不会处于无效状态。

如果不是，那么，这自然就意味着该规则是特定于命令的，不应驻留在域实体中。因此，违反此规则将导致不应执行的动作，但不会处于无效的模型状态。