经常使用instanceof是一种好习惯吗？

Question

场景。我正在编写与游戏相关的代码。在那个游戏中，Player（它也是一个类）有一个Item 的列表。还有其他类型的项目继承自Item，例如ContainerItem、DurableItem 或WeaponItem。

显然，只有List<Item> 对我来说非常方便。但是当我得到玩家的物品时，我区分物品类型的唯一方法是使用instanceof关键字。我确定我已经读过依赖它是不好的做法。

在这种情况下可以使用它吗？还是我应该重新考虑我的所有结构？

Answer 1

假设我正在编写一些库存代码：

public void showInventory(List<Item> items) {
    for (Item item : items) {
        if (item instanceof ContainerItem) {
            // container display logic here
        }
        else if (item instanceof WeaponItem) {
            // weapon display logic here
        }
        // etc etc
    }
}

这将编译并正常工作。但是它错过了面向对象设计的一个关键思想：您可以定义父类来做一般有用的事情，并让子类填充特定的重要细节。

上述的替代方法：

abstract class Item {
    // insert methods that act exactly the same for all items here

    // now define one that subclasses must fill in themselves
    public abstract void show()
}
class ContainerItem extends Item {
    @Override public void show() {
        // container display logic here instead
    }
}
class WeaponItem extends Item {
    @Override public void show() {
        // weapon display logic here instead
    }
}

现在我们可以在所有子类中查看库存显示逻辑的show() 方法。我们如何访问它？简单！

public void showInventory(List<Item> items) {
    for (Item item : items) {
        item.show();
    }
}

我们将所有特定于项目的逻辑保留在特定的项目子类中。这使您的代码库更易于维护和扩展。它减少了第一个代码示例中长 for-each 循环的认知压力。并且它准备好 show() 可以在您尚未设计的地方重复使用。

Answer 2

恕我直言，使用instanceof 是一种代码味道。简而言之 - 它使您的代码程序化，而不是面向对象。执行此操作的 OO 方法是使用 visitor pattern。

访问者模式还允许您在其之上轻松构建decorators 和chain of responsibility，从而实现关注点分离，从而使代码更短、更简洁、更易于阅读和测试。

您还真的需要知道确切的班级吗？你不能利用多态性吗？毕竟Axe 和Sword 一样是Weapon。

Answer 3

也许你应该重新考虑并尝试使用多态性来实现你的List<Item> 想法。

这里有一些可能对您的问题有所帮助的参考资料：

• Prefer polymorphism over instanceof and downcasting
• instanceof versus getClass in equals Methods (Interview with Josh Bloch)
• Polymorphism and Interfaces（请参阅有关何时使用 instanceof 的部分）

---

（来自Is instanceof considered bad practice? If so, under what circumstances is instanceof still preferable?的引用）

Answer 4

你应该重新考虑你的结构，非元代码中的instanceof 几乎总是反模式的标志。尝试在Item-class/interface 中定义所有Items 的共同行为（比如有图片、描述以及单击它们时发生的事情），使用abstract-keyword if适当的，然后使用polymorphism来实现细节。

Answer 5

如果你容易理解就好了。

将分支逻辑从它们自然属于的所有位置移至子类不一定是一个好主意。它可能会创建错误的依赖关系；它可能会导致类臃肿，并且可能难以导航和理解。

归根结底，这一切都是关于如何在一维空间中以多个维度的关注点物理组织我们的代码。这不是一个小问题，它是主观的，没有灵丹妙药。

特别是，我们的行业继承了上个世纪基于那个时代的技术和经济限制而制定的许多经验法则。例如，工具非常有限；程序员非常昂贵；应用程序发展缓慢。

其中一些规则今天可能不再适用。

Answer 6

我不一定认为 instanceof 对于知道自己在做什么并使用它来避免编写更复杂的代码来绕过它的编码人员来说是坏事。万物皆有用，也有误用。

话虽如此，您提供的描述不需要instanceof。有多种方法可以在没有 instanceof 的情况下实现这一点，并且（最重要的是）替代解决方案必须比使用 instanceof 更好。不要仅仅使用非实例化解决方案来避免实例化，因为你听说它很糟糕。

我认为对于您的方案，非实例解决方案有利于使解决方案更易于扩展。

for (Item i: items) {
    if (ItemTypes.WEAPON_ITEM.equals(i.getType)) {
        processWeaponType(i);
    }

}

或

for (Item i: items) {
    if (WeaponItem.class.equals(i.getType)) {
        processWeaponType(i);
    }

}