Пара различий между полем объекта данных и свойством Java Bean

Демонстрируется пример объявления и использования поля объекта данных (java-проект «Модель данных» — fishbolt.org/java/org.fishbolt.model/doc/article.ru.html ). Приводится сравнение с Java Beans, объясняются преимущества.

В модели, поле объекта данных представлено интерфейсом IDataField. Параметр этого интерфейса определят тип значения поля.
Интерфейс содержит методы setValue и getValue, которые используются для установки и чтения значения поля, соответственно. Так, например, значение поля IDataField<Integer> будет устанавливаться с помощью метода setValue(Integer) и извлекаться с помощью вызова getValue() (возвращаемый тип Integer).
Время жизни экземпляра поля IDataField совпадает со временем жизни экземпляра объекта данных (IDataObject), в котором поле содержиться. Т.е., значение поля объекта данных может многократно меняться в поле данных объекта, однако экземпляр поля данных ( IDataField) у объекта данных никогда не меняется.

В объекте данных (т.е. объекте типа IDataObject), поле объявляется как константа:

final static FieldDeclaration<String> name = new FieldDeclaration<String>();
Предположим, что наш объект данных называется Department.
Cослаться на поле данных можно указанием константы Department.name. Объявление этой константы в объекте данных определяет наличие соответствующего поля данных (IDataField) у экземпляра. Константа используется для получения значения поля — в базовом интерфейсе объекта данных (интерфейс IDataObject) объявлен метод:

<T> IDataField<T> getDataField(FieldDeclaration<T> declaration) ;

Получить значение поля, представленного константой name, можно следующим образом:

Department d = ...;

IDataField<String> dataField = d.getDataField(Depatment.name);
String name = dataField.getValue();

Или можно использовать сокращённый вызов при помощи вспомогательного класса ModelUtil:

String name = ModelUtil.getValue(d, Depatment.name);

Сравнивая поле объекта данных со свойством Java-бина можно сказать, что технология Java Beans не выделяет свойство экземпляра бина в отдельный объект, то есть, нет объекта, который заворачивает в себе значение свойства бина и “живёт” вместе с бином. Такой объект, конечно, неявно присутствует в уме разработчика как пара имя свойства — экземпляр бина. К сожалению, наличие такого объекта лишь в уме разработчика не позволяет ссылаться на объект в коде.

Конечно, разработчик может без особого труда создать класс, который бы представлял пару
имя свойства — экземпляр бинаоднако использование такого класса приведет к значительному удорожанию таких действий с кодом, как удаление свойства бина или изменение имени свойства. В коде невозможно сослаться на свойство бина таким образом, что бы, впоследствии, при удалении или изменении этого свойства ошибка ссылки выявлялась бы на этапе компиляции (возможно лишь на этапе выполнения). Проблема вызвана тем, что сослаться на свойство бина можно только путем использования строки (String) с названием свойства (так уж исторически устроена Java).

Полагаю, для части читателей настал момент усомниться в необходимости объекта-завёртки значения поля. Одним из наиболее весомых аргументов против является повышенный расход памяти по сравнению с Java Beans. Противовесом является то самоописание и простота представления единицы информации (значении поля), которые позволяют легко создавать большее количество повторно используемых компонентов, взаимодействующих с информацией.

Возможность ссылаться на поле объекта данных до создания экземпляра (т.е. ссылаться на константу с описанием) позволяет создавать целые механизмы, которые будут конфигурироваться с помощью объявления констант, и при этом проверка целостности ссылок в коде будет обеспечиваться на этапе компиляции.

Наглядным примером такого механизма является проект «Пользовательский интерфейс модели данных в среде Eclipse» fishbolt.org/eclipse/org.fishbolt.model.eclipse/doc/plugin.article.ru.html. В этом проекте связь данных с компонентами пользовательского интерфейса осуществляется именно таким декларативным способом.