假设我正在编写一些库存代码：
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() 准备好在您尚未设计的地方重用。
Record类为例 - 我们有两种记录类型 - File和Directory。通用的东西可以抽象成记录，但是假设File有一个download()方法。因此，从Set<Record>中你不能下载文件，除非你知道它们确实是文件。所以如果你遇到这种情况，多态就不够了，但在大多数情况下它是最好的解决方案，所以给这个好答案加上+1。 - Svetlin Zarevinstanceof是一种代码异味。简单来说，它会使您的代码程序化，而不是面向对象的。使用访问者模式是面向对象的方式。decorator和chain of responsibility，从而实现关注点分离，得到更短、更清洁、更易于阅读和测试的代码。Axe就像Sword一样都是Weapon。instanceof方式 - 这是一种称为“双重分派”的技术，通过访问者模式实现。但别误会了。我的答案与他的不同也不相反。它是互补的。如果您没有正确实现类层次结构，则无法实现访问者。 - Svetlin Zarevinstanceof几乎总是反模式的标志。请尝试在Item类/接口中定义所有Item共有的行为（例如具有图片、描述以及单击它们时会发生某些事情），如果合适的话，请使用abstract关键字，并利用多态性来实现具体内容。List<Item> 想法。如果你觉得容易理解，那就没问题。
将分支逻辑从自然归属的位置移动到子类中并不一定是一个好主意。这可能会创建错误的依赖关系，导致过于庞大的类，并且可能难以导航和理解。
最终，这一切都关乎如何在一维空间中物理组织我们的代码，同时考虑多个方面的问题。这不是一个微不足道的问题，它是主观的，并且没有万灵药。
特别是，我们的行业继承了许多经验规则，这些规则是基于上个世纪的技术和经济约束制定的。例如，工具非常有限；程序员费用高昂；应用演变缓慢。
这些规则中的一些在今天可能已经不再适用。
我并不认为instanceof对于那些知道如何使用它来避免编写更复杂代码的程序员是坏事。万物皆有用，也有误用。
话虽如此，你提供的描述并不需要使用instanceof。有各种方法可以实现这一点，而且（最重要的是）替代方案必须比使用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);
}
}
instanceof 更易读。就性能而言，instanceof 真的很快；它绝对比比较我们自己的 type 字段要快；甚至可能比将 Class 与 == 进行比较还要快。 - ZhongYu
instanceof是设计不良的症状。诀窍是使用双重分派或访问者模式。在网上搜索一下。 - Jean-Baptiste Yunèsinstanceof的细节，那么给您举一些例子会更容易些。 - MadConan