How to setup a (ui) class in a readable way ?

Question

I'm pretty new to java (and java's OO model) and i can't really think of a nice way to do this :
I'm creating a UI, a JFrame which has a JTabbedPane (with 8 tabs)
and each of these 8 tabs contains either a few listboxes or a pretty complex form (think: 8 textboxes, dragdrop lists, buttons, labels, etc.).
now i know how to code this but tossing it all in a single class will make it HUGE and thus pretty unmaintainable (i'm a pretty 'clean' programmer but still, thousands of lines in a method never looks good).
Does anyone have any tips on how to organise my "ui building" code in multiple classes or interfaces or something else.
When push comes to shove and the application is running the tabs do share some functionality (example: if you choose an item from a list in tab2 then the complex form on tab3 gets filled with the values of that item), so they are not truely separate entities.
I usually have no trouble organising my code in a nice manner but visual/ui code in java doesn't really seem to fit into my way of thinking :)
Any help would be appreciated !

Answer 1

If a panel/tab has about 10 input components (input
boxes, lists, buttons, etc.) and each of them has a
label (pretty common) then you're easily talking
about 25+ swing components (10x component, 10x label,
some additional scrollpanes e.a.). Now imagine the
form with 8 of these tabs , and we're talking about a
few hundred of components.Once again, break them up. Why do all eight tabs have to be in the same class? You could easily define eight different classes that return or are eight different JComponent or JPanel instances and add each as a tab. Making each it's own class might not be appropriate in your case, but the point is they don't need to be in the same class or even the same source file.
A typical Swing component needs about 5 (for a
JButton) to 15 (for a JList in a scrollpane) lines of
code to be initialized and tossed in the
panel/layoutmanager. This means that my hundreds of
components (together) need thousands of lines of
code, just to place them.Where do you see redundancy in your code? Can you extract any of this redundancy to a separate method that can be called once for each component? Why does the initialization even have to be in the same place as the actual placement?
For this reason, im looking for a good way to
separate the UI (The view part of MVC) into
sub-components. Reusability isn't really my concern
at the moment, maintainability and good practise is.
Besides, my skills with swing are too limited at the
moment to be thinking about abstraction/reusability
within the UI anyway.I don't think your knowledge of Swing matters. We're not talking about creating a robust custom table widget. We're talking about something as simple as moving code that creates a JPanel to show an address to another class called "AddressPanel" for example.
I guess the real trouble is with me anyway, i'm
pretty new to java (and swing) and although i really
like the things it CAN do, i don't like the amount of
code it takes to do it (mostly a swing problem i
guess). I'm a big fan of abstraction and interfaces
and all, but the amount of code needed to use simple
components (such as listboxes) and placement on the
form (whole layoutmanagers paradygm) just keeps the
codebase huge and ugly.There were many design decisions made with Swing that I disagree with. For example, it's massive depedency on concrete inheritance and the implications it has, forcing you into concrete inheritance yourself. However, in the end it's pretty powerful and you can use these things as a benefit. For example, separate intialization and layout. They do not need to be in the same place.
Maybe instead of worrying too much how to separate
stuff in the "View" part of MVC), i should be looking
at alternatives to Swing that are more appealing to
my desire of having a clean codebase (maybe SWT or
Buoy is any better? honoustly haven't looked yet) or
maybe i should just ride it out and write a little
wrapper/framework around swing myself (step by
step).I am not aware of any solution out there as robust and consistent as Swing that is supported on all Java platforms. SWT sounds nice, but you rely on Eclipse to continue to support it on your target platforms. Maybe that's acceptable to you, but if it's not you're probably stuck with Swing.
A typical java project of mine is (imo) pretty nicely
setup (overall model, separation of functionality,
codestyle, the use of 3rd party packages etc.) but
has the UI in there as the ugly black sheep ;p (with
either big classes or lots of classes).Refactoring is the best approach in my opinion. Check out Martin Fowler's book "Refactoring" if you're not familiar with what I mean. It doesn't require you to completely rethink your design or make massive changes. You just need to make little improvements, and in the end it adds up to a good solution. At least that's my experience.
I'm just coding java applications for myself (usually
more into non-UI programming) so i have the luxury of
being able to try different approaches without
worrying about a timetable. Best thing to do now is
to think my current model over (compare it to true
MVC and see what's different) and try to implement
the "Command pattern" stuff and see where that gets
me.The hardest part is figuring out how to implement MVC well using Swing. Or at least that's been the most difficult thing for me. I understand MVC. I understand Swing. Combining the two to meet my requirements has been a challenge and I still don't have the answer. After the fifth "re-design" I gave up the notion of figuring it out and decided to just do it and refactor whenever I saw something that smelled. So far it's working out pretty well.