• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Design of Java Swing GUI

 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am noticing that as I build different menus within JFrame ame that my code is getting messy. I am also going to add some ActionListener which is even going to make it more cluttered.
Is there a way to separate code for components , menus and ActionListeners in different classes and if so how?
 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You could try the following approach:

Use real classes instead of anonymous classes. Every ListenerClass implements only one Use-Case / Functionality. The Classname should describe the UseCase. Then you can organize the classes in one or more packages to cluster them by categories that fit to the Use-Cases that the Listener in the package implements.

That means, you create an hierarchy of abstraction, that organizes the functionality like a tree-structure.

If some day later somebody has to maintain the Listeners he/she can find the Listener by first looking for a package that fits to the UseCase and then for the UseCase itself. Since you will have less packages then Classes it will be easier and faster to find the Listener.
 
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm a big fan of declaring Actions as fields in the form that I'm creating. I usually use a helper class to create actions from lambdas. Keep the actions small by just letting the event handler delegate to a method of your form. This has two main benefits: You can easily create multiple controls that perform the same action (such as menu items, tool buttons and regular buttons), and you can disable actions when they're not valid for a certain state of your form.

In your other topic, I showed a skeletal form you could use to implement your text editor. Let's initialize the actions to show you what I mean:

As you can see, we've done all the wiring up by using a utility class to initialize the actions, and using the actions to create menu items. All that's left is to actually implement the methods that are called by the actions. I think this is nice and clean design, and it should be pretty obvious what this code does.

Here's the utility class you can use to create handlers. Just add more utility methods for different kinds of events you want to handle:
 
Stribor Kab
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
lamda is neat but I wasn't able to use in my eclipse (java 7) on ubuntu.
Where would you put the code for creating jframe, panels etc?
 
Stephan van Hulst
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you can't use lambda expressions, then get rid of the utility class, and just initialize your actions like this:

If your form needs additional panels, just add them to your frame in the initComponents() method. If you need to be able to reference components in your other methods, add them as fields instead of as local variables. For instance, textArea and fileChooser must be accessed in the openFile() method, so they're private fields of the class; menuBar is only needed inside the initComponents() method, so it's a local variable.

If the panels you want to add become very complex, instead of laying them out in the initComponents() method, make a new class out of them that extend JPanel. You can then lay them out in their own initComponents() method. However, don't expose the components they contain. Instead, design an API for the panel so you can just let them act on part of your model.

Let's say so have a panel that holds some components for application settings:

You see that if we incorporate this SettingsPanel in some form, we don't have to mess with the controls that it contains. We just let it do it's magic, and when we're happy, we call the saveSettings() method on it.
 
I am going to test your electrical conductivity with this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic