Properties and Bindings - JavaFX 8: A Definitive Guide to Building Desktop, Mobile, and Embedded Java Clients - page 150

Understanding the WritableValue Interface
This might be the simplest subsection in the entire chapter, for the WritableValue interface is truly as simple as
it looks. Its purpose is to inject the getValue() and setValue() methods into implementations of this interface.
All implementation classes of WritableValue in the JavaFX properties and bindings framework also implement
ObservableValue , therefore you can make an argument that the value of WritableValue is only to provide the
setValue() method.
You have seen the setValue() method at work in the motivating example.
Understanding the ReadOnlyProperty Interface
The ReadOnlyProperty interface injects two methods into its implementations. The getBean() method should return
the Object that contains the ReadOnlyRroperty or null if it is not contained in an Object . The getName() method
should return the name of the ReadOnlyProperty or the empty string if the ReadOnlyProperty does not have a name.
The containing object and the name provide contextual information about a ReadOnlyProperty . The contextual
information of a property does not play any direct role in the propagation of invalidation events or the recalculation of
values. However, if provided, it will be taken into account in some peripheral calculations.
In our motivating example, the intProperty is constructed without any contextual information. Had we used the
full constructor to supply it a name:
intProperty = new SimpleIntegerProperty(null, "intProperty", 1024);
the output would have contained the property name:
intProperty = IntegerProperty [name: intProperty, value: 1024]
Understanding the Property Interface
Now we come to the bottom of our key interfaces hierarchy. The Property interface has as its superinterfaces all
four interfaces we have examined thus far: Observable , ObservableValue , ReadOnlyProperty, and WritableValue .
Therefore it inherits all the methods from these interfaces. It also provides five methods of its own:
void bind(ObservableValue<? extends T> observableValue);
void unbind();
boolean isBound();
void bindBidirectional(Property<T> tProperty);
void unbindBidirectional(Property<T> tProperty);
You have seen two of the methods at work in the motivating example in the last section: bind() and unbind() .
Calling bind() creates a unidirectional binding or a dependency between the Property object and the
ObservableValue argument. Once they enter this relationship, calling the set() or setValue() methods on
the Property object will cause a RuntimeException to be thrown. Calling the get() or getValue() methods on the
Property object will return the value of the ObservableValue object. And, of course, changing the value of the
ObservableValue object will invalidate the Property object. Calling unbind() releases any existing unidirectional
binding the Property object may have. If a unidirectional binding is in effect, the isBound() method returns true ;
otherwise it returns false .
Calling bindBidirectional() creates a bidirectional binding between the Property caller and the
Property argument. Notice that unlike the bind() method, which takes an ObservableValue argument, the
bindBidirectional() method takes a Property argument. Only two Property objects can be bound together