在 Java 中避免 instanceof

新手上路,请多包涵

拥有一系列“instanceof”操作被认为是“代码味道”。标准答案是“使用多态性”。在这种情况下我该怎么做?

基类有许多子类;他们都不在我的控制之下。类似的情况是 Java 类 Integer、Double、BigDecimal 等。

 if (obj instanceof Integer) {NumberStuff.handle((Integer)obj);}
else if (obj instanceof BigDecimal) {BigDecimalStuff.handle((BigDecimal)obj);}
else if (obj instanceof Double) {DoubleStuff.handle((Double)obj);}

我确实可以控制 NumberStuff 等等。

我不想在几行就可以的地方使用多行代码。 (有时我制作一个 HashMap 映射 Integer.class 到 IntegerStuff 的实例,BigDecimal.class 到 BigDecimalStuff 的实例等。但今天我想要更简单的东西。)

我想要像这样简单的东西:

 public static handle(Integer num) { ... }
public static handle(BigDecimal num) { ... }

但是 Java 并不是那样工作的。

我想在格式化时使用静态方法。我格式化的东西是复合的,其中一个 Thing1 可以包含一个 Thing2 数组,一个 Thing2 可以包含一个 Thing1 数组。当我像这样实现我的格式化程序时遇到了问题:

 class Thing1Formatter {
  private static Thing2Formatter thing2Formatter = new Thing2Formatter();
  public format(Thing thing) {
      thing2Formatter.format(thing.innerThing2);
  }
}
class Thing2Formatter {
  private static Thing1Formatter thing1Formatter = new Thing1Formatter();
  public format(Thing2 thing) {
      thing1Formatter.format(thing.innerThing1);
  }
}

是的,我知道 HashMap 并且多一点代码也可以解决这个问题。但相比之下,“instanceof”似乎更具可读性和可维护性。有什么简单又不臭的吗?

2010 年 5 月 10 日添加的注释:

事实证明,将来可能会添加新的子类,而我现有的代码将不得不优雅地处理它们。在这种情况下,Class 上的 HashMap 将不起作用,因为找不到该 Class。一连串的 if 语句,从最具体的开始到最一般的结束,可能毕竟是最好的:

 if (obj instanceof SubClass1) {
    // Handle all the methods and properties of SubClass1
} else if (obj instanceof SubClass2) {
    // Handle all the methods and properties of SubClass2
} else if (obj instanceof Interface3) {
    // Unknown class but it implements Interface3
    // so handle those methods and properties
} else if (obj instanceof Interface4) {
    // likewise.  May want to also handle case of
    // object that implements both interfaces.
} else {
    // New (unknown) subclass; do what I can with the base class
}

原文由 Mark Lutton 发布,翻译遵循 CC BY-SA 4.0 许可协议

阅读 667
2 个回答

您可能对 Steve Yegge 的 Amazon 博客中的这篇文章感兴趣: “当多态性失败时” 。本质上,他是在处理这样的情况,多态性导致的麻烦多于它解决的问题。

问题是要使用多态性,您必须使每个“切换”类的“处理”部分的逻辑——即在这种情况下为 Integer 等。显然这是不切实际的。有时,从逻辑上讲,它甚至不是放置代码的正确位置。他建议将“instanceof”方法作为几种弊端中较小的一种。

与所有被迫编写难闻代码的情况一样,将其固定在一个方法(或最多一个类)中,这样气味就不会泄露出去。

原文由 DJClayworth 发布,翻译遵循 CC BY-SA 2.5 许可协议

正如评论中强调的那样,访问者模式将是一个不错的选择。但是如果不直接控制目标/接受者/访问者,您就无法实现该模式。这是访问者模式仍然可以在这里使用的一种方式,即使您无法通过使用包装器直接控制子类(以 Integer 为例):

 public class IntegerWrapper {
    private Integer integer;
    public IntegerWrapper(Integer anInteger){
        integer = anInteger;
    }
    //Access the integer directly such as
    public Integer getInteger() { return integer; }
    //or method passthrough...
    public int intValue() { return integer.intValue(); }
    //then implement your visitor:
    public void accept(NumericVisitor visitor) {
        visitor.visit(this);
    }
}

当然,包装 final 类可能被认为是它自己的味道,但也许它很适合您的子类。就我个人而言,我不认为 instanceof 是一种难闻的气味,特别是如果它仅限于一种方法并且我会很乐意使用它(可能超过我上面自己的建议)。正如您所说,它非常易读、类型安全且可维护。一如既往,保持简单。

原文由 Chris Knight 发布,翻译遵循 CC BY-SA 3.0 许可协议

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题