Evitando instanceof em Java

Ter uma cadeia de operações "instanceof" é considerado um "cheiro de código". A resposta padrão é "use polimorfismo". Como eu faria isso neste caso?

Existem várias subclasses de uma classe base; nenhum deles está sob meu controle. Uma situação análoga seria com as classes Java Integer, Double, BigDecimal etc.

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);}

Eu tenho controle sobre NumberStuff e assim por diante.

Não quero usar muitas linhas de código onde algumas linhas serviriam. (Às vezes eu faço um HashMap mapeando Integer.class para uma instância de IntegerStuff, BigDecimal.class para uma instância de BigDecimalStuff etc. Mas hoje eu quero algo mais simples.)

Eu gostaria de algo tão simples quanto isto:

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

Mas Java simplesmente não funciona dessa maneira.

Eu gostaria de usar métodos estáticos durante a formatação. As coisas que estou formatando são compostas, em que Thing1 pode conter um array Thing2s e um Thing2 pode conter um array de Thing1s. Tive um problema quando implementei meus formatadores como este:

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);
  }
}

Sim, eu conheço o HashMap e um pouco mais de código pode consertar isso também. Mas o "instanceof" parece tão legível e sustentável em comparação. Existe algo simples, mas não fedorento?

Nota adicionada em 10/05/2010:

Acontece que novas subclasses provavelmente serão adicionadas no futuro e meu código existente terá que lidar com elas normalmente. O HashMap na classe não funcionará nesse caso porque a classe não será encontrada. Uma cadeia de instruções if, começando com a mais específica e terminando com a mais geral, é provavelmente a melhor, afinal:

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
}

Você pode estar interessado nesta entrada do blog de Steve Yegge na Amazon: "quando o polimorfismo falha" . Essencialmente, ele está tratando de casos como este, quando o polimorfismo causa mais problemas do que resolve.

O problema é que para usar o polimorfismo você tem que fazer a lógica de "manipular" parte de cada classe de 'comutação' - ou seja, inteiro etc. neste caso. Obviamente, isso não é prático. Às vezes, nem é logicamente o lugar certo para colocar o código. Ele recomenda a abordagem 'instância' como sendo o menor de vários males.

Como em todos os casos em que você é forçado a escrever um código fedorento, mantenha-o restrito a um método (ou no máximo uma classe) para que o cheiro não vaze.

Conforme destacado nos comentários, o padrão do visitante seria uma boa escolha. Mas sem controle direto sobre o alvo / aceitador / visitee você não pode implementar esse padrão. Esta é uma maneira pela qual o padrão de visitante ainda pode ser usado aqui, mesmo que você não tenha controle direto sobre as subclasses usando wrappers (tomando Integer como exemplo):

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);
    }
}

Claro, encerrar uma aula final pode ser considerado um cheiro próprio, mas talvez seja um bom ajuste para suas subclasses. Pessoalmente, não acho instanceofque seja um cheiro tão ruim aqui, especialmente se for confinado a um método e eu ficaria feliz em usá-lo (provavelmente sobre minha própria sugestão acima). Como você disse, é bastante legível, seguro para digitação e manutenção. Como sempre, mantenha as coisas simples.

Em vez de um enorme if, você pode colocar as instâncias que manipula em um mapa (chave: classe, valor: manipulador).

Se a pesquisa por chave retornar null, chame um método manipulador especial que tenta encontrar um manipulador correspondente (por exemplo, chamando isInstance()cada chave no mapa).

Quando um manipulador for encontrado, registre-o na nova chave.

Isso torna o caso geral rápido e simples e permite que você controle a herança.

Você pode usar reflexão:

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...
}

Você pode expandir a ideia de lidar genericamente com subclasses e classes que implementam certas interfaces.

Você pode considerar o padrão da Cadeia de Responsabilidade . Para o seu primeiro exemplo, algo como:

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;
   }
}

e da mesma forma para seus outros manipuladores. Então, é o caso de amarrar os StuffHandlers em ordem (do mais específico para o menos específico, com um manipulador de 'fallback' final) e seu código de despachante é justo firstHandler.handle(o);.

(Uma alternativa é, em vez de usar uma cadeia, apenas ter um List<StuffHandler>em sua classe de despachante e fazê-lo percorrer a lista até handle()retornar verdadeiro).

Acho que a melhor solução é HashMap com Class como chave e Handler como valor. Observe que a solução baseada em HashMap é executada em complexidade algorítmica constante θ (1), enquanto a cadeia de cheiro de if-instanceof-else é executada em complexidade algorítmica linear O (N), onde N é o número de links na cadeia if-instanceof-else (ou seja, o número de classes diferentes a serem tratadas). Portanto, o desempenho da solução baseada em HashMap é assintoticamente maior N vezes do que o desempenho da solução de cadeia if-instanceof-else. Considere que você precisa lidar com diferentes descendentes da classe Message de forma diferente: Message1, Message2, etc. Abaixo está o snippet de código para manipulação baseada em 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);
        }
    }
}

Mais informações sobre o uso de variáveis ​​do tipo Class em Java: http://docs.oracle.com/javase/tutorial/reflect/class/classNew.html

Basta ir com a instanceof. Todas as soluções alternativas parecem mais complicadas. Aqui está uma postagem do blog que fala sobre isso: http://www.velocityreviews.com/forums/t302491-instanceof-not-always-bad-the-instanceof-myth.html

Eu resolvi esse problema usando reflection(cerca de 15 anos atrás, na era pré-genéricos).

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

Eu defini uma classe genérica (classe base abstrata). Eu defini muitas implementações concretas de classe base. Cada classe concreta será carregada com className como parâmetro. Este nome de classe é definido como parte da configuração.

A classe base define o estado comum em todas as classes concretas e as classes concretas modificarão o estado substituindo as regras abstratas definidas na classe base.

Naquela época, não sei o nome desse mecanismo, que ficou conhecido como reflection.

Poucas alternativas são listadas neste artigo : Mape enumalém da reflexão.