instanceof 被认为是不好的做法吗？如果是这样，在什么情况下instanceof仍然更可取？

Question

多年来，我一直试图尽可能避免 instanceof。在适用的情况下使用多态性或访问者模式。我想它只是在某些情况下简化了维护......还有其他需要注意的缺点吗？

不过我确实在 Java 库中到处看到它，所以我想它有它的位置？什么情况下比较好？这是不可避免的吗？

Answer 1

它在 equals 的库存实现中肯定占有一席之地。例如，

public boolean equals ( Object o )
{
  if ( this == o )
  {
     return true;
  }

  if ( ! (o instanceof MyClass) )
  {
    return false;
  }

  // Compare fields
  ...
}

关于instanceof，需要了解的一件有趣的事情是它的LHS 可以为null，在这种情况下，表达式的计算结果为false。

Answer 2

我可以想象一些情况，例如，你有一个库的一些对象，你无法扩展它们（或者这样做会很不方便），也许与你的一些对象混合在一起，所有这些对象都具有相同的基类，一起在一个收藏。
我想在这种情况下，使用 instanceof 来区分对这些对象的某些处理可能会很有用。

同上，在遗留代码的某些维护中，您不能在许多旧类中注入一些新行为，只是为了添加新的小功能或一些错误修复......

Answer 3

我认为当你绝对需要知道对象的类型时，instanceof 是最好的选择。

一种不好的做法是拥有大量实例，一个挨着另一个，并根据它们调用对象的不同方法（当然是强制转换）。
这可能反映出层次结构需要重新思考，甚至​​可能需要重构。

Answer 4

当您处于纯 OO 模型中时，instanceof 绝对是一种代码味道。

但是，如果您没有使用 100% OO 模型，或者需要从外部向其中注入内容，则可以使用 instanceof 或等效项（isXXX()、getType() >, ...) 可以有其用途。

一般的“规则”是尽可能避免它，特别是当您控制类型层次结构并且可以使用子类型多态性时。这个想法不是询问对象是什么类型并对其执行某些操作，而是直接或通过访问者（本质上是双重多态性）间接要求对象执行某些操作。

Answer 5

我同意它可能有难闻的气味。很多实例，特别是在链接在一起的 if 块中，闻起来很糟糕。

有时它的行为方式可能是你意想不到的......我曾经发生过一次：（

Class B extends A
Class C extends A

B b = new B();
C c = new C();

b instanceof B -> true
b instanceof C -> true
c instanceof C -> true
c instanceof B -> true

在我的例子中，这是由于 hibernate 制作代理对象而发生的......但这只是代码依赖于 instanceof 的情况是有风险的）

Answer 6

它可以很好地用作铸造前的健全性检查；除了检查对象的类型是否正确之外，它还检查对象是否不为空。

if (o instanceof MyThing) {
    ((MyThing) o).doSomething(); // This is now guaranteed to work.
} else {
    // Do something else, but don't crash onto ClassCast- or NullPointerException.
}

Answer 7

如果是创造工厂呢？
例如

public static Cage createCage(Animal animal) {
  if (animal instanceof Dog)
    return new DogHouse();
  else if (animal instanceof Lion)
    return new SteelCage();
  else if (animal instanceof Chicken)
    return new ChickenWiredCage();
  else if (animal instanceof AlienPreditor)
    return new ForceFieldCage();
  ...
  else
    return new GenericCage();
}