Java GUI'ing

[imported_Ned Flanders]

Hey,

I'm pretty good at coding in Java, and I know how to create GUI's using the standard Swing/AWT classes - But with a new program I'm coding some elements need pretty big methods to create them.

At the moment for a program I am producing I have a Client class with
1300+ lines of code in it. I also have a 'dialog' package with 6 different diaogs in it.
I have created the dialog classes because they are distinctly separate elements to the GUI, but now I am questioning whether other elements could be 'classified' - i.e

My menu bar can either be the classic JMenuBar or a better looking JTabbedPane/JPanel combo - The code for the actionListeners and menu construction is about 650 lines.

I have a list bar (shows a list of items which are selectable) - The method takes a Vector of strings and creates a list of JLabels witha generic mouseAdapter used to toggle bold as the mouse passes over it. When clicked, another method is called to build and show a JPopupMenu.

At the moment, I am having problems managing the 1300+ lines of code in one class. Version 2 of my program is needed!

I guess my question is:

When does the amount of code (or needed functionality?) in a method to produce a particular element of my GUI justify it to be put into its own class?

Many thanks.

 

[postmortemIA]

They way you define the problem, if it is entity by itself, then it should be new class.

 

[imported_Ned Flanders]

Does anyone else have anything to add?

I would also like to add - Is it not better to have loosely coupled classes? So how far should I go to accomplish this - Should I make my actionListeners in my Client class and pass them over to one of the 'sub' classes (I think this would have to be the case if I decided to create the menu bar in it's own class)

Thanks again

 

[kamper]

Coders do a lot of dumb things in the name of 'loose coupling'. Usually it leads to incredibly obfuscated code that is still hard to change. I know because I'm frequently guilty of over abstraction 😛

That doesn't mean that you shouldn't try to break up stuff that doesn't belong together, just not to do it only for the sake of doing it. If you are having problems managing a very large class, then analyze why it's difficult and break it up in a way that will specifically address that problem. I'm not much of a gui expert but a pretty useful way to break it up is to separate code that defines how the gui looks from code that defines what it does.