In my earlier article, The Bean Class for Java Programming, I presented how I want you, my students, to code a data or model class in your assignments. That style of bean class is widely used in frameworks such as Hibernate, Java Server Faces, CDI and others. There is one variant of that class that you need to know about and that is the JavaFX bean class.
JavaFX is the modern GUI framework that is the successor to Swing as it was the successor to AWT. One important characteristic of JavaFX is that the observable pattern is baked into its beans, pun intended. When a JavaFX bean is bound or connected to a JavaFX control. such as a text field, changes to the control can automatically update the bean and changes to the bean updates the control. This is an important feature in the Model View Controller pattern that JavaFX promotes.
A JavaFX bean, when properly constructed, can be a drop-in replacement for a Java bean in most instances. It is expected to adhere to all the mandatory, optional and even bonus features I described in the earlier article. Let’s begin by reviewing the fields from that article.
I have added an additional field to make this bean a little more interesting. The field will represent the date that the book was published.
To make this bean observable we must change how we declare these fields. JavaFX introduced a family of wrapper classes called property classes. These property classes exist for the primitive types, the String, List, Map, Object, Set and a catch all for any other class type. These classes come in read / write as well as read only versions. They also come in abstract and concrete classes. The abstract class is the property type (LHS) and the concrete class is the instantiation (RHS). Here is a table of the read / write property classes.
The abstract property classes define the required methods of a property in a general way. The concrete class may override the general methods but do not add any additional methods. JavaFX has other concrete property classes that can appear on the right-hand side. The concrete classes extend the abstract class. This is an example of pure inheritance.
This means that we need to rewrite the fields as follows.
The next change that we make from the original bean is that we now must have a constructor. These property fields are null references to abstract classes so you must instantiate them. If you do not plan to have a non-default constructor then all you need is something like this:
Each of the references to an abstract class is instantiated with a concrete class. The concrete classes all accept an appropriate value of the underlying type in their constructor.
If we need to have both a default and non-default constructor they can be written like this:
The default constructor uses Java’s ability to have a constructor call another constructor by overloading. The non-default constructor can now be used to create an instance of the object and at the same time this class has the required default constructor.
The setters and getters must also be modified. These methods are expected to get or set the value inside the property object and not the property itself. This is easy to do as property classes have a get and set method to handle this. Here are the setters and getters.
With this syntax we now have a drop in replacement for standard Java beans as described in my first article. This is not complete yet. We are using property classes to achieve an observable pattern. To accomplish this JavaFX controls must be bound or connected to the individual fields. The controls need a reference to the property object. Only the equivalent of a getter is required. There is no naming convention because we write out the method name when we do the binding. The most common naming approach is to add the word Property to the variable name. Here are the getters for the properties.
There is not a setter for a property because once created and bound to a control it must not be replaced. Only its contained value can be altered.
The hashCode, equals, toString and compareTo methods need to be modified to use the get and set methods of the properties.
The only change required to our Comparator class is to declare the beans as JavaFX beans rather than Java beans.
Put all together this is what our JavaFX bean looks like.
The test program for this bean is almost identical to the original BeanTester but with the LocalDate added and used in a Comparator function.
JavaFX does require that you use JavaFX beans as described here. They are only required if you intend to take advantage of binding to controls. If binding is not required then an ordinary Java bean should be used.
To summarize these two articles, if you are not using JavaFX then I expect you to use the Java bean class for data and models in the work you submit to me. In a JavaFX application I expect you to use the JavaFX bean whenever binding is required.