A couple of differences between the data object field and the Java Bean property

An example of declaring and using a data object field is shown (java-project “Data Model” - fishbolt.org/java/org.fishbolt.model/doc/article.ru.html ). A comparison with Java Beans is given, the advantages are explained.

In the model, the data object field is represented by the IDataField interface. The parameter of this interface will determine the type of the field value.
The interface contains the setValue and getValue , which are used to set and read the field value, respectively. For example, the value of the IDataField<Integer> field will be set using the setValue(Integer) method and retrieved using the getValue() call (return type Integer ).
The lifetime of an instance of an IDataField field IDataField same as the lifetime of an instance of the data object ( IDataObject ) in which the field is contained. That is, the value of a data object field can change many times in the data field of an object, but an instance of the data field ( IDataField ) of a data object never changes.

In a data object (that is, an object of type IDataObject ), the field is declared as a constant:

final static FieldDeclaration<String> name = new FieldDeclaration<String>();
Suppose our data object is called Department .
You can refer to the data field by specifying the Department.name constant. The declaration of this constant in the data object determines whether an instance has a corresponding data field ( IDataField ). The constant is used to get the field value - the IDataObject method is declared in the basic interface of the data object ( IDataObject interface):
')
<T> IDataField<T> getDataField(FieldDeclaration<T> declaration) ;

You can get the value of the field represented by the name constant as follows:

Department d = ...;

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

Or you can use an abbreviated call using the ModelUtil helper class:

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

Comparing the data object field with the Java bean property, we can say that the Java Beans technology does not allocate the bean instance property into a separate object, that is, there is no object that wraps the value of the bean property and “lives” along with the bean . Such an object, of course, is implicitly present in the developer’s mind as a pair of a property name — an instance of a bean . Unfortunately, the presence of such an object only in the mind of the developer does not allow to refer to the object in the code.

Of course, the developer can easily create a class that would represent a couple
property name is an instance of a bean; however, using such a class will significantly increase the cost of such actions with code such as deleting a bean's property or changing the name of a property. In the code, it is impossible to refer to the bin property in such a way that, later, when removing or changing this property, a link error would be detected at the compilation stage (it is possible only at the execution stage) . The problem is caused by the fact that it is possible to refer to a bean property only by using a string (String) with the name of the property (this is how Java is historically arranged).

I suppose, for some readers, the time has come to doubt the need for a wrapper object of field value. One of the most powerful arguments against is the increased memory consumption compared to Java Beans. The counterweight is the self-description and simplicity of the presentation of the information unit (field value), which makes it easy to create a larger number of reusable components that interact with the information.

The ability to refer to a data object field before creating an instance (ie, refer to a constant with a description) allows you to create entire mechanisms that will be configured by declaring constants, while checking the integrity of references in the code will be provided at the compilation stage.

A good example of such a mechanism is the project “Data Interface User Interface in the Eclipse Environment” fishbolt.org/eclipse/org.fishbolt.model.eclipse/doc/plugin.article.ru.html. In this project, data is linked to user interface components in just such a declarative way.