java reflection polymorphism instanceof chain-of-responsibility

Evitando instanceof en Java



reflection polymorphism (8)

Como se destaca en los comentarios, el patrón de visitante sería una buena opción. Pero sin control directo sobre el objetivo / aceptor / visitee, no puede implementar ese patrón. Esta es una de las formas en que el patrón de visitante podría seguir utilizándose aquí aunque no tenga control directo sobre las subclases mediante el uso de envolturas (tomando Entero 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 se adapte bien a tus subclases. Personalmente, no creo que el instanceof sea ​​tan malo aquí, especialmente si está limitado a un método y lo usaría felizmente (probablemente por encima de mi propia sugerencia). Como dices, es bastante legible, seguro y fácil de mantener. Como siempre, mantenlo simple.

Tener una cadena de operaciones "de instancia" se considera un "olor de código". La respuesta estándar es "usar 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 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, etc.

No quiero usar muchas líneas de código donde algunas líneas harían. (A veces hago una asignación de HashMap 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 utilizar métodos estáticos al formatear. Las cosas que estoy formateando son compuestas, donde un Thing1 puede contener un array Thing2s y un Thing2 pueden contener un conjunto 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 arreglarlo. Pero el "instanceof" parece tan legible y mantenible en comparación. ¿Hay algo simple pero no huele mal?

Nota añadida 5/10/2010:

Resulta que las nuevas subclases probablemente se agregarán 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 por la más específica y terminando por 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 }

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 complejidad algorítmica constante θ (1), mientras que la cadena olorosa de if-instanceof-else se ejecuta en 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 más alto N veces que el rendimiento de la solución de cadena if-instanceof-else. Considere que necesita manejar diferentes descendientes de la clase Message de forma 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

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

Si la búsqueda mediante la tecla devuelve un null , llame a un método de isInstance() especial que intente encontrar un controlador coincidente (por ejemplo, llamando a isInstance() en cada tecla del mapa).

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

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

He resuelto este problema usando la reflection (alrededor de 15 años atrás en la era pre-genérica).

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 .

Pocas alternativas más se enumeran en este article : Map y enum aparte de la reflexión.

Podría considerar el patrón de 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 controladores. Entonces, es un caso de encadenar los StuffHandlers en orden (de más específico a menos específico, con un manejador final de ''respaldo''), y su código de despachador es solo firstHandler.handle(o); .

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

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

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

Como en todos los casos en que se le obliga a escribir un código maloliente, manténgalo abrochado en un método (o como máximo en una clase) para que no se filtre el olor.

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.