5

我有以下代码来检查游戏单位是玩家还是敌人。这是仅有的两类。我可以删除 isEnemy 方法并像 if(!isPlayer) 一样运行对敌人的所有检查，但我个人认为 if(isEnemy) 使代码的意图更加清晰。是否有任何既定的编码风格对这种情况有什么要说的？

public boolean isPlayer(Unit unit) {
    return unit == player;
}

public boolean isEnemy(Unit unit) {
    for (Unit e : enemies) {
        if (unit.equals(e))
            return true;
    }
    return false;
}
4

5 回答 5

6

对于您的情况，您只有两种可能的状态-它们要么是敌人，要么是玩家。如果他们是玩家，他们就不是敌人。最简洁的表达方式是!isPlayer.

如果您有其他可能的状态，那么您可能想要查看其他状态的某种枚举。

作为一般经验法则： 不要重复自己。如果您复制的代码的一部分发生了更改（可能是为了修复错误），那么您必须更改该错误的每一次出现。它可能变成维护的噩梦。

于 2012-12-25T04:02:17.543 回答
3

就个人而言，我会实现isEnemy()as!isPlayer()但拥有assert运行循环的 an 以确保它确实是一个敌人。

于 2012-12-25T04:00:04.083 回答
2

我认为两种方法都可以接受。如果 isEnemy() == !isPlayer() 我会考虑将 isEnemy() 实现为：

public boolean isEnemy(Unit unit) {
  return !isPlayer(unit);
}

这样，您可以获得具有两种特定方法的可读性，但不必重复自己，就好像您可以调整 isPlayer() 并影响这两种方法一样。

于 2012-12-25T04:36:39.180 回答
1

在我看来，这是完全可以接受的。特别是在大型项目中，可读性非常重要。还要考虑到，如果您将来添加第三个角色，那么您将无法使用 if (!isPlayer)。

于 2012-12-25T03:57:32.117 回答
1

通过查看您的代码，您正在识别敌人是否存在于集合“敌人”中。所以对你来说，敌人本质上不是不是玩家的人。如果您想强制执行此语义，那么我认为您不应该使用 isEnemy() 方法。

您可能需要 isEnemy() 方法的另一个原因是，如果您看到其他类型的可能性说 Ally。拥有 isEnemy() 方法将使添加更简单、更清晰。

但是，如果以上 2 个条件无效，则将其删除。正如他们所说的YAGNI :)

于 2012-12-25T04:32:33.767 回答