Evitando instanceof en Java

Tener una cadena de operaciones de "instancia de" se considera un "olor a código". La respuesta estándar es "utilizar polimorfismo". ¿Cómo lo haría en este caso?

Hay varias subclases de una clase base; ninguno de ellos está bajo mi control. Una situación análoga sería con las clases de 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);}

Tengo control sobre NumberStuff y demás.

No quiero usar muchas líneas de código donde bastaría con unas pocas líneas. (A veces hago una asignación HashMap de Integer.class a una instancia de IntegerStuff, BigDecimal.class a una instancia de BigDecimalStuff, etc. Pero hoy quiero algo más simple).

Me gustaría algo tan simple como esto:

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

Pero Java simplemente no funciona de esa manera.

Me gustaría usar métodos estáticos al formatear. Las cosas que estoy formateando son compuestas, donde un Thing1 puede contener una matriz Thing2s y una Thing2 puede contener una matriz de Thing1s. Tuve un problema cuando implementé mis formateadores de esta manera:

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

Sí, sé que HashMap y un poco más de código también pueden solucionarlo. Pero la "instancia de" parece tan legible y fácil de mantener en comparación. ¿Hay algo simple pero que no huele mal?

Nota agregada el 5/10/2010:

Resulta que probablemente se agregarán nuevas subclases en el futuro, y mi código existente tendrá que manejarlas con elegancia. El HashMap on Class no funcionará en ese caso porque no se encontrará la clase. Una cadena de declaraciones if, comenzando con la más específica y terminando con la más general, es probablemente la mejor después de todo:

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
}

Quizás le interese esta entrada del blog de Amazon de Steve Yegge: "cuando falla el polimorfismo" . Esencialmente, está abordando casos como este, cuando el polimorfismo causa más problemas de los que resuelve.

El problema es que para usar polimorfismo tienes que hacer que la lógica de "manejar" sea parte de cada clase de "conmutación", es decir, Integer, etc. en este caso. Claramente, esto no es práctico. A veces, ni siquiera lógicamente es el lugar correcto para colocar el código. Él recomienda el enfoque de 'instancia de' como el menor de varios males.

Al igual que con todos los casos en los que se ve obligado a escribir código maloliente, manténgalo abotonado en un método (o como máximo en una clase) para que el olor no se escape.

Como se destaca en los comentarios, el patrón de visitantes sería una buena opción. Pero sin un control directo sobre el objetivo / aceptor / visitante no puede implementar ese patrón. Aquí hay una forma en que el patrón de visitante podría seguir usándose aquí aunque no tenga control directo sobre las subclases mediante el uso de envoltorios (tomando Integer como ejemplo):

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

Por supuesto, envolver una clase final podría considerarse un olor propio, pero tal vez sea una buena opción para tus subclases. Personalmente, no creo instanceofque sea un olor tan malo aquí, especialmente si se limita a un método y lo usaría felizmente (probablemente por encima de mi propia sugerencia anterior). Como dices, es bastante legible, seguro para escribir y fácil de mantener. Como siempre, hazlo simple.

En lugar de una enorme if, puede poner las instancias que maneja en un mapa (clave: clase, valor: manejador).

Si la búsqueda por clave regresa null, llame a un método de controlador especial que intenta encontrar un controlador que coincida (por ejemplo, llamando isInstance()a cada clave en el mapa).

Cuando se encuentra un controlador, regístrelo con la nueva clave.

Esto hace que el caso general sea rápido y simple y le permite manejar la herencia.

Puedes usar la reflexión:

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

Puede ampliar la idea para manejar genéricamente subclases y clases que implementan ciertas interfaces.

Podría considerar el patrón Cadena de responsabilidad . Para su primer ejemplo, 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;
   }
}

y luego de manera similar para sus otros manejadores. Entonces es un caso de encadenar los StuffHandlers en orden (del más específico al menos específico, con un controlador final 'alternativo'), y su código de despachador es solofirstHandler.handle(o); .

(Una alternativa es, en lugar de usar una cadena, simplemente tener un List<StuffHandler>en su clase de despachador y hacer que recorra la lista hasta que handle()devuelva verdadero).

Creo que la mejor solución es HashMap con Class como clave y Handler como valor. Tenga en cuenta que la solución basada en HashMap se ejecuta en una complejidad algorítmica constante θ (1), mientras que la cadena de olor de if-instanceof-else se ejecuta en una complejidad algorítmica lineal O (N), donde N es el número de enlaces en la cadena if-instanceof-else (es decir, el número de clases diferentes que se manejarán). Por lo tanto, el rendimiento de la solución basada en HashMap es asintóticamente N veces mayor que el rendimiento de la solución de cadena if-instanceof-else. Considere que necesita manejar diferentes descendientes de la clase Message de manera diferente: Message1, Message2, etc. A continuación se muestra el fragmento de código para el manejo basado en 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);
        }
    }
}

Más información sobre el uso de variables de tipo Class en Java: http://docs.oracle.com/javase/tutorial/reflect/class/classNew.html

Simplemente vaya con la instancia de. Todas las soluciones alternativas parecen más complicadas. Aquí hay una publicación de blog que habla de ello: http://www.velocityreviews.com/forums/t302491-instanceof-not-always-bad-the-instanceof-myth.html

He resuelto este problema usando reflection(alrededor de 15 años atrás en la era anterior a los genéricos).

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

He definido una clase genérica (clase base abstracta). He definido muchas implementaciones concretas de la clase base. Cada clase concreta se cargará con className como parámetro. Este nombre de clase se define como parte de la configuración.

La clase base define el estado común en todas las clases concretas y las clases concretas modificarán el estado anulando las reglas abstractas definidas en la clase base.

En ese momento, no sé el nombre de este mecanismo, que se ha conocido como reflection.

En este artículo se enumeran pocas alternativas más : Mapy enumademás de la reflexión.