【问题标题】:Warrior, Wizards and Game Rules战士、巫师和游戏规则
【发布时间】:2018-08-10 20:28:23
【问题描述】:

不久前,我正在处理problem,并且提出了责任以及他们应该去哪里的话题。在我的链接问题中,大学是拥有所有规则并确保每个注册学生都拥有所需文件的机构和班级。

这让我想起了 Eric Lippert 的一篇博文:Wizards and Warriors

上面写着:

我们一直在谈论“规则”,因此显然业务 该程序的域包括称为“规则”的东西,而那些 规则与业务域中的所有其他对象交互。所以 那么“规则”应该是一个类吗?我不明白为什么不!这是什么 程序从根本上讲。似乎可能有 成百上千个这样的规则,而且它们可以改变 时间,因此将它们编码为类似乎是合理的。

规则:

  • 战士只能使用剑。

  • 法师只能使用法杖。

我的问题是如何确定GameRulesclass中传递的具体对象是否可以携带?

public final class GameRules {

    public static boolean verifyifwizardcancarry(Weapon weapon){
        boolean canCarry  = false
        if weapon is a a staff set canCarry to true
        return canCarry;
    }
 }

public abstract class Player{   

   private List<Weapon> weapons;
   // constructor and OOP goodness left out

   public abstract void add(Weapon weapon);

}


public final class Wizard extends Player{

   @Override 
   public void add(Weapon weapon){

      if(GameRules.verifyifwizardcancarry(weapon){
          // - code to add weapon to inventory
      }
    }
 }

如何验证传递给GameRules classWeapon 实际上是Sword?从阅读来看,instanceofgetClass() 的使用被认为是代码异味。

我找到了this 的答案,但它违反了 LSP 并且违背了博客声明的内容,即它不应该抛出异常,也没有真正回答我的问题。

【问题讨论】:

  • 你为什么关心它是否是Sword?如果是这样,它肯定与Weapon 的所有其他实现有所不同。甚至更好,如果你的问题是它是否可以携带,为什么Weapons 没有属性canBeCarried
  • @FedericoklezCulloca 向导只是玩家的一种实现(顺便说一句,在向导中实现玩家),角色决定了我猜的可用武器
  • this blog 中的Visitor 模式可能对您有用。也就是说,instanceof 仍然是一场哲学辩论,因为虽然它肯定可以用在臭名昭著的方式中,但它也有其合法用途(默认为 equals() 实现为初学者)。
  • @LanceToth - 已更正,它现在扩展了 Player。发帖时出错
  • @FedericoklezCulloca - 正如博文中所指出的,Weapon 不必担心谁携带它,规则规定了允许哪个角色携带什么物品。

标签: java oop inheritance


【解决方案1】:

据此Java dynamic binding and method overriding

创建这样的函数会在添加剑时调用,而不是武器的任何其他子项

public void add(Sword sword){
    //nope
}

如果只能装备一种(或几种)武器,也可以这样做,但覆盖功能会给出否定响应。

【讨论】:

  • 但是你会将instanceof 的检查从Player.add 内部移动到其他正在向所有玩家分发武器的封闭对象。
【解决方案2】:

我认为在您的情况下您无法避免使用 instanceof 运算符。我的建议是你让每个具体的Player 自己负责确定它可以携带什么武器。所以删除 GameRules.verifyifwizardcancarry 并在玩家之间传播这个逻辑,这样Wizard 会检查 instanceof 的武器,而其他玩家也会这样做。

【讨论】:

  • 这可能是最好的答案,但我要再等一会儿再检查,谁知道 Eric Lippert 本人可能会提供帮助!
  • @Nexusfactor:遗憾的是,我今天没有时间参与。也许下周吧。 :-)
猜你喜欢
  • 2011-06-26
  • 2023-04-04
  • 1970-01-01
  • 2010-10-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-10-18
  • 1970-01-01
相关资源
最近更新 更多