EnumMap podría ser considerada como una alternativa razonable a Java Beans?

Question

curioso si alguien ha considerado el uso de EnumMap en lugar de Java Beans, en particular los "objetos de valor" (con ningún comportamiento)? A mí me parece que una ventaja sería que el nombre de una "propiedad" sería directamente accesible desde la enumeración de respaldo, sin necesidad de reflexión, y por lo tanto yo asumiría que sería más rápido.

Answer 1

puede ser un poco más rápido que el uso de la reflexión (no me mido, no encontré ningún métricas en Google tampoco); sin embargo, hay grandes inconvenientes de este enfoque:

1. Estás perdiendo la seguridad de tipos. En lugar de int getAge() y String getName() todo es Object get(MyEnum.FIELD_NAME). Que va a proporcionar para un cierto código feo y errores en tiempo de ejecución allí mismo.

2. Todas las sutilezas JavaBean que hemos llegado a amar y disfrutar (por ejemplo, anotaciones a nivel de la propiedad) se han ido.

3. Ya que se puede tener ningún comportamiento en absoluto, la aplicabilidad de este enfoque parece bastante limitado.

La conclusión es - si realmente necesita verdad que el supuesto aumento en el rendimiento :-) (que tendrá que medir para demostrar que existe) este puede ser un enfoque viable en circunstancias muy específicas. ¿Es una alternativa viable a los JavaBeans en general? Ciertamente no.

Answer 2

Un grano está destinado a ser, por lo tanto los métodos setter mutables. EnumMap es comparable en velocidad a la utilización de un HashMap con números enteros como la clave, pero son claves son inmutables. Frijoles y EnumMaps sirven para dos propósitos diferentes. Si todas las claves son conocidos en tiempo de diseño y están garantizados para no cambiar nunca, a continuación, utilizando un EnumMap va a estar bien.
Actualización de un grano es mucho más simple que el cambio de la enumeración respaldo de la EnumMap con muchas menos posibilidades de crear errores en el código de aguas abajo.

Answer 3

Me escribió una clase Record que mapea claves a valores y trabaja delegando a un EnumMap completamente sincronizada. La idea es que un registro puede conseguir nuevos campos en tiempo de ejecución, mientras que el Bean no puede. Mi conclusión es que con esta flexibilidad tiene un impacto en el rendimiento. Aquí está un funcionamiento comparando la clase de registro a un Bean completamente sincronizada. Por 10 millones de operaciones:

Record  set(Thing, a)  458 ms
Bean    setThing(a)    278 ms
Record  get(Thing)     398 ms
Bean    getThing       248 ms

Por lo tanto, hay algo que ganar en el conocimiento de sus objetos de datos y escribir una clase que los modelos estáticamente. Si usted quiere tener nuevos campos rellenados a sus datos en tiempo de ejecución, que le costará.

Answer 4

No entiendo cómo puede quitar 'profileration clase' con EnumMaps. A menos que tenga una enumeración genérica con propiedades 20 y pico de volver a utilizar para cada 'frijol', todavía estás inventando una enumeración a utilizar para cada mapa de enumeración, por ejemplo.

public enum PersonDTOEnum {
     A, S, L;
}

en lugar de

class Person {

    int a;
    int s;
    String l;

    // getters + setters elided
}

Por no hablar de que todo es una cadena ahora.

Answer 5

No había especificado previamente esta, pero estoy trabajando con un conjunto de resultados. Por eso quiero dar esta respuesta en aras de la exhaustividad.

Commons / de BeanUtil 'RowSetDynaClass' podría ser el medio entre la plancha de caldera excesiva asociada con los granos de hormigón, y las limitaciones de EnumMap