避免在 Java 中使用实例

instanceof reflection java polymorphism chain-of-responsibility

2022-08-31 09:44:53

具有“实例”操作链被视为“代码异味”。标准答案是“使用多态性”。在这种情况下，我该怎么做？

一个基类有许多子类;他们都不在我的控制之下。类似的情况是Java类整数，双精度，大十进制等。

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映射Intege.class到IntegerStuff，BigDecimal的实例.class BigDecimalStuff的实例等。但今天我想要更简单的东西。

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

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

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

我想在格式化时使用静态方法。我正在格式化的内容是复合的，其中Thing1可以包含一个数组Thing2s，而Thing2可以包含Thing1s的数组。当我像这样实现格式化程序时，我遇到了一个问题：

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和更多的代码也可以解决这个问题。但相比之下，“实例”似乎如此可读和可维护。有什么简单但不臭的东西吗？

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

事实证明，将来可能会添加新的子类，而我现有的代码将不得不优雅地处理它们。在这种情况下，类上的哈希映射将不起作用，因为找不到该类。一连串的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
}

答案 1

你可能对Steve Yegge的亚马逊博客中的这个条目感兴趣：“当多态性失败时”。从本质上讲，他正在处理这样的情况，当多态性引起的麻烦多于解决时。

问题在于，要使用多态性，您必须使每个“切换”类的“handle”逻辑成为一部分 - 即在这种情况下的整数等。显然，这是不切实际的。有时，从逻辑上讲，它甚至不是放置代码的正确位置。他建议“实例”方法作为几种邪恶中较小的一种。

与所有被迫编写臭代码的情况一样，请将其扣在一种方法（或最多一个类）中，以免气味泄漏出来。

答案 2

正如评论中强调的那样，访客模式将是一个不错的选择。但是，如果没有对目标/接受者/访问者的直接控制，你就无法实现这种模式。以下是一种可能仍然在这里使用访问者模式的方式，即使您不能通过使用包装器直接控制子类（以 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);
    }
}

当然，包装最终类可能被认为是它自己的气味，但也许它非常适合你的子类。就个人而言，我不认为这里的气味那么难闻，特别是如果它仅限于一种方法，我很乐意使用它（可能是我上面的建议）。正如你所说，它非常可读，类型安全且可维护。一如既往，保持简单。instanceof