Some thoughts:
- Don't add such bindings to the GUI classes, look for a pattern like MVC
- Unidirectional change propagation (input -> output as in your example) is usually never problematic, but in many cases, full synchronization of editable component groups is required. So one may keep that in mind during development of the simple case for good reusability of any custom class or interface.
- Avoid infinite circular updates with a flag, rather than with a comparison of component values.
- Whatever you do, keep things separated and whatever pattern you use, don't add bidirectional references (e.g. among GUI class <-> controller)
Regardless of MVC, there could be a controller class, getting all necessary references to the UI objects (i.E. JPanel
s with nested JTextField
s and JLabel
s, etc.) via constructor.
On construction, that controller can attach itself to those nested components.
The controller should preferably contain nested, inner or perhaps anonymous classes for implementing the listener interfaces, rather than adding the listener interface to the controller itself. First, to encapsulate these listeners and second, to avoid the event source distinction, if the same interface needs to be implemented for multiple components (sources). These listener implementations (perhaps pretty generic PropertyChangeListener
's) could then act as, or use mediator objects (as mentioned), for updating other components.