避免在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可以包含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和更多的代码也可以解决该问题。但是通过比较，“ instanceof”似乎是如此可读和可维护。有没有简单但没有臭味的东西？

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

事实证明，将来可能会添加新的子类，而我现有的代码将不得不优雅地处理它们。在这种情况下，基于HashMap的类将无法正常工作，因为找不到该类。从最具体的开始到最一般的结束的一串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
}

您可能对Steve Yegge的Amazon博客中的条目感兴趣：“多态性失败时”。本质上，他正在处理这样的情况，即多态性带来的麻烦多于解决的麻烦。

问题在于，要使用多态性，您必须使每个“切换”类的“处理”逻辑成为一部分-在这种情况下即为Integer等。显然，这是不切实际的。有时从逻辑上讲，这甚至都不是放置代码的正确位置。他建议采用“ instanceof”方法，以减少一些弊端。

与所有被迫编写有臭味的代码的情况一样，请以一种方法（或最多一类）将其保持扣紧状态，以使气味不会泄漏出去。

正如评论中强调的那样，访客模式将是一个不错的选择。但是，如果不能直接控制目标/接受者/被访问者，就无法实现该模式。即使您没有通过使用包装程序直接控制子类的方式，也可以在这里仍然使用访客模式的一种方式（以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这里的气味并不难闻，特别是如果它仅限于一种方法并且我会很乐意使用它（可能超出我上面的建议）。就像您说的那样，它相当可读，具有类型安全性和可维护性。与往常一样，保持简单。

if您可以将处理的实例放置在地图中（而不是一个巨大的实例）（键：类，值：处理程序）。

如果按键查找返回null，则调用一个特殊的处理程序方法，该方法尝试查找匹配的处理程序（例如，通过调用isInstance()映射中的每个键）。

找到处理程序后，将其注册在新密钥下。

这使一般情况变得快速而简单，并允许您处理继承。

您可以使用反射：

public final class Handler {
  public static void handle(Object o) {
    try {
      Method handler = Handler.class.getMethod("handle", o.getClass());
      handler.invoke(null, o);
    } catch (Exception e) {
      throw new RuntimeException(e);
    }
  }
  public static void handle(Integer num) { /* ... */ }
  public static void handle(BigDecimal num) { /* ... */ }
  // to handle new types, just add more handle methods...
}

您可以扩展该思想，以一般性地处理实现某些接口的子类和类。

您可以考虑“责任链”模式。对于第一个示例，类似：

public abstract class StuffHandler {
   private StuffHandler next;

   public final boolean handle(Object o) {
      boolean handled = doHandle(o);
      if (handled) { return true; }
      else if (next == null) { return false; }
      else { return next.handle(o); }
   }

   public void setNext(StuffHandler next) { this.next = next; }

   protected abstract boolean doHandle(Object o);
}

public class IntegerHandler extends StuffHandler {
   @Override
   protected boolean doHandle(Object o) {
      if (!o instanceof Integer) {
         return false;
      }
      NumberHandler.handle((Integer) o);
      return true;
   }
}

然后类似地为您的其他处理程序提供服务。然后是按顺序将StuffHandlers串在一起的情况（最具体到最不具体，带有最终的“后备”处理程序），而您的调度程序代码就是firstHandler.handle(o);。

（一种替代方法是，不使用链，而List<StuffHandler>在调度程序类中仅添加一个，并使其在列表中循环，直到handle()返回true 为止）。

我认为最好的解决方案是HashMap，将Class作为键，将Handler作为值。请注意，基于HashMap的解决方案以恒定的算法复杂度θ（1）运行，而if-instanceof-else的嗅觉链以线性算法复杂度O（N）运行，其中N是if-instanceof-else链中的链接数（即要处理的不同类的数量）。因此，基于HashMap的解决方案的性能比if-instanceof-else链解决方案的性能渐近N倍。考虑到您需要以不同的方式处理Message类的不同后代：Message1，Message2等。以下是基于HashMap的处理的代码段。

public class YourClass {
    private class Handler {
        public void go(Message message) {
            // the default implementation just notifies that it doesn't handle the message
            System.out.println(
                "Possibly due to a typo, empty handler is set to handle message of type %s : %s",
                message.getClass().toString(), message.toString());
        }
    }
    private Map<Class<? extends Message>, Handler> messageHandling = 
        new HashMap<Class<? extends Message>, Handler>();

    // Constructor of your class is a place to initialize the message handling mechanism    
    public YourClass() {
        messageHandling.put(Message1.class, new Handler() { public void go(Message message) {
            //TODO: IMPLEMENT HERE SOMETHING APPROPRIATE FOR Message1
        } });
        messageHandling.put(Message2.class, new Handler() { public void go(Message message) {
            //TODO: IMPLEMENT HERE SOMETHING APPROPRIATE FOR Message2
        } });
        // etc. for Message3, etc.
    }

    // The method in which you receive a variable of base class Message, but you need to
    //   handle it in accordance to of what derived type that instance is
    public handleMessage(Message message) {
        Handler handler = messageHandling.get(message.getClass());
        if (handler == null) {
            System.out.println(
                "Don't know how to handle message of type %s : %s",
                message.getClass().toString(), message.toString());
        } else {
            handler.go(message);
        }
    }
}

有关在Java中使用类型为Class的变量的更多信息：http : //docs.oracle.com/javase/tutorial/reflect/class/classNew.html

只需使用instanceof。所有变通办法似乎都比较复杂。这是一个讨论此问题的博客文章：http : //www.velocityreviews.com/forums/t302491-instanceof-not-always-bad-the-instanceof-myth.html

我已经解决了这个问题reflection（在前泛型时代大约有15年的历史了）。

GenericClass object = (GenericClass) Class.forName(specificClassName).newInstance();

我定义了一个泛型类（抽象基类）。我定义了基类的许多具体实现。每个具体的类都将使用className作为参数加载。此类名称定义为配置的一部分。

基类在所有具体类中定义公共状态，具体类将通过​​覆盖基类中定义的抽象规则来修改状态。

当时我还不知道这种机制的名称， reflection。

几个备选方案中列出这文章：Map与enum从反射分开。