Можно ли считать EnumMap разумной альтернативой Java-бинам?

Question

Интересно, кто-нибудь задумывался об использовании EnumMap вместо Java-бинов, в частности, «объектов-значений» (без поведения)? Мне кажется, что одним из преимуществ было бы то, что имя «свойства» было бы напрямую доступно из вспомогательного Enum без необходимости размышления, и поэтому я бы предположил, что оно будет быстрее.

Answer 1

Я написал класс Record, который отображает ключи на значения и работает путем делегирования полностью синхронизированной EnumMap. Идея состоит в том, что запись может получить новые поля во время выполнения, тогда как Бин не может. Мой вывод заключается в том, что с такой гибкостью приходит снижение производительности. Вот прогон, сравнивающий класс Record с полностью синхронизированным Бином. За 10 миллионов операций:

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

Итак, есть что-то, что можно получить, зная ваши объекты данных и создав класс, который моделирует их статически. Если вы хотите, чтобы новые поля добавлялись к вашим данным во время выполнения, это будет стоить вам.

Answer 2

Это может быть немного быстрее, чем при использовании отражения (я не измерял его, не нашел ни одного показателя в Google); однако у этого подхода есть большие недостатки:

1. Вы теряете безопасность типа. Вместо int getAge() и String getName() все равно Object get(MyEnum.FIELD_NAME). Это обеспечит некрасивый код и ошибки во время выполнения.

2. Все javabean тонкости, которые мы полюбили и поняли (например, аннотации на уровне свойств), исчезли.

3. Поскольку у вас НИЧЕГО ПОВЕДЕНИЯ не может быть, применимость этого подхода представляется довольно ограниченной.

Суть в том, что - если вам действительно нужно это предполагаемое :-) повышение производительности (которое вы должны будете измерить, чтобы доказать, что оно существует), это может быть жизнеспособным подходом в очень конкретных обстоятельствах. Является ли это жизнеспособной альтернативой javabeans в целом? Конечно, нет.

Answer 3

Бин предназначен для изменчивости, следовательно, методы установки. EnumMap сопоставим по скорости с использованием HashMap с целыми числами в качестве ключа, но ключи неизменны. Beans и EnumMaps служат двум различным целям. Если все ключи известны во время разработки и гарантированно никогда не изменится, тогда использование EnumMap будет в порядке.
Обновление bean-компонента намного проще, чем изменение вспомогательного Enum EnumMap с гораздо меньшей вероятностью возникновения ошибок в коде.

Answer 4

Я не понимаю, как вы можете удалить «профилирование классов» с помощью EnumMaps. Если у вас нет общего перечисления с 20 с лишним свойств для повторного использования для каждого «боба», вы все равно придумываете перечисление для использования с каждой картой перечисления, например,

public enum PersonDTOEnum {
     A, S, L;
}

в отличие от

class Person {

    int a;
    int s;
    String l;

    // getters + setters elided
}

Не говоря уже о том, что теперь все является строкой.

Answer 5

Я ранее не указывал это, но я работаю с ResultSet. Поэтому я хочу дать этот ответ для полноты картины.

Commons / BeanUtil's "RowSetDynaClass" может быть удачной средой между избыточным образцом, связанным с конкретными бобами, и ограничениями EnumMap