Поля атрибутов против карты атрибута-значения

Question

У меня есть класс (java) с примерно 10 атрибутами, многие из которых потенциально остаются неинициализированными и недоступны при жизни объекта.

Поэтому я рассматриваю возможность использования Map<String,Object> в качестве имени-атрибута -> карты атрибут-значения вместо множества полей для экономии ресурсов.
Теперь мне интересно, существуют ли какие-либо официальные или неофициальные правила, когда и как выбрать одну из описанных возможностей. Сколько атрибутов должен иметь класс, прежде чем я должен рассмотреть возможность использования такой карты? Стоит ли вообще его использовать?

Заранее спасибо за ваш совет / мнения по этому поводу.

Answer 1

Хорошо, вы делаете это для экономии памяти, я полагаю, потому что вы явно не экономите ресурсы ЦП, обращаясь к карте вместо поля. Итак, давайте посмотрим, насколько хорошо это работает: (при условии, что 64-битная JVM без сжатых операций - что нереально, но не должно слишком сильно изменять результаты, вы можете легко вычислить это самостоятельно)

По сути, поле в java никогда не будет занимать более 8 байт (хорошо, размер слова для ссылок). Таким образом, это означает, что для вашего класса с 10 полями, при условии, что все они не используются, лучшее, что мы можем сохранить, это 8 * 10 байт = 80 байт.

Теперь вы хотите заменить это одним HashMap - это означает, что мы уже использовали 8 дополнительных байтов для этого. Кроме того, HashMap всегда инициализируется, поэтому мы получаем заголовок: 2 слова header + reference + 3 ints + float + 1 array (2 слова overhead, размер 4 байта, 16 ссылок по умолчанию), который занимает 182 bytes памяти.

Могу ли я поздравить вас с сохранением колоссальных -110 bytes!

PS: я думаю, что наименьшее возможное значение по умолчанию для резервного массива хэш-набора равно 2, так что вы можете использовать это и получить четность. Но как только вы сохраняете объекты в наборе, вы получаете дополнительные издержки от объектов Wrapper, используемых классом. Так что на самом деле это плохая идея.

Answer 2

Я не думаю, что карта - это хорошая идея.

• с точки зрения ОО, поля являются свойствами Типа и его подтипа.Подумайте о наследовании и полиморфизме, как вы можете заставить Карту достичь этих символов OO?

• , даже если говорить о стиле кода, это не делает ваши коды чище.Как вы справляетесь с типом литья?Обработка исключений?эти коды будут намного больше, чем объявление поля и методы получения / установки (если они у вас есть)

Answer 3

Дело не в том, сколько у вас различных атрибутов, а в том, как они используются и что нужно.Map предоставит большую гибкость, чтобы не иметь атрибутов или иметь разные атрибуты для разных экземпляров или добавлять атрибуты позже (путем добавления элементов в Map).Но если атрибуты имеют разные типы String, Integer, Doubles и т. Д., Это потребует создания Map типа Object и приведения всех значений при их использовании (намного больше работы для вас).

Answer 4

Мне нравится идея карты для атрибутов, которые действительно являются необязательными и «несущественными».В противном случае вам понадобится целая куча подклассов и / или вам всегда нужно будет проверять наличие нулей в ваших методах получения.

Что касается типизации, я часто пишу код, передавая значение по умолчанию в качестве второго аргумента,используйте его, чтобы определить тип возвращаемого значения.например,

  int getValue(String key, int defaultValue);
  double getValue(String key, double defaultValue);
  String getValue(String key, String defaultValue);

Звонящий, а не карта, должен знать тип.YMMV, нравится ли вам этот стиль ...

Однако для атрибутов, которые являются "существенными", я предпочитаю реальные поля.