Java Swing: separating UI component from logic behaviour - how do you approach this?

What I do, in NetBeans for example:

• create a UI component class, suffixed with Swing component type, e.g. JPanel, e.g. MyUIWidgetJPanel
• create a logic/behaviour class to handle the behaviour/logic, i.e. what happens when the UI component is used, e.g. buttons within it pressed etc., MyUIWidgetLogic

I may also link components/logic together using references, if the behaviour/outcome of one component influences/impacts another, e.g. some options displayed are no longer relevant, or to give context sensitive options.

What do you think of this? Good? 开发者_Go百科Bad?

What do you do?

I tend to use the Presentation Model Pattern.

Essentially it seems to be what you do: create a class which encompasses the logic, separate to the UI class. The UI classes shouldn't contain logic - only the code needed to display the interface.

You can then bind your front-end values to the back-end presentation model class using something like JGoodies Binding (I understand that Spring RCP is pretty good for this as well).

I found this article How to Write Custom Swing Component helpful as an example of UI delegate plumbing.

Filthy Rich Clients by Chet Haase and Romain Guy is widely recommended for tips on visually rich client applications.

Since Swing components communicate using Events via the Event Dispatch Thread, you typically will provide ActionListener implementations to the elements that you're interested in (like a JButton). It is these ActionListener implementations that will contain the logic, but keep in mind that if you don't use threading, your UI element (like the JButton) will not be responsive while your ActionListener is doing some calculations and holding control.

What you are describing is a design pattern called MVC (Model View Controller) It is not undisputed, but it is the most popular way of separating concerns in a GUI. It also ensures that when you have several representations (views) of the same data (model) you can be sure all of them are updated when the data changes. The Controller part of MVC takes care of telling the userinterface which parts should be enabled (amongst other things).

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller