aspose file tools*
The moose likes Swing / AWT / SWT and the fly likes Advice on refactoring Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Advice on refactoring" Watch "Advice on refactoring" New topic
Author

Advice on refactoring

miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
hi

i'm in the process of refactoring this application of mine that basically has a TabbedPane with three panels, each one having lots of components (textfileds, labels, buttons, textareas, splitPanels, tables and so on)

in the original code i was able to completely separate logic from view, so refactoring the swing part (using layout managers instead of null layout) is being quite straight

in this refactoring (and perhaps due to my inexperience) my layouts end up with lots of nested panels

in the original application all the components were generated by the IDE and i could access them easily at a reach of a getXXX(), while in this version i have to traverse the panel's hierarchy to reach each one

for example: buttonX is inside panelButtons, which is inside rightPanel, which itself belongs to firstPanel

so i would apreciate advice on the following:
would it be wiser to create an API for this main panel with public getXXX() for every component i need for logic, instead of leaving it as it is and leave the task of reaching every component to calling code?

thanks in advance


java amateur
Maneesh Godbole
Saloon Keeper

Joined: Jul 26, 2007
Posts: 9995
    
    7

in this refactoring (and perhaps due to my inexperience) my layouts end up with lots of nested panels

Why do you feel this is bad? In my experience, having nested panels is easier to understand as well as maintain as compared to having one single container with lots of child components added directly. Relax. You are doing good.

For buttons, except in cases where I needed to enable/disable them (e.g. for authentication purposes) you rarely required to access them directly. Most of the times the actionPerformed defined in their corresponding action classes does the trick.
For rest of the fields, one would usually define them as instance variables. Depending on the requirement, you would define the getter/setters. e.g. if you got a password field, a get/set password is all you require from outside the class. These methods in turn would access the specific fields/components.

I am not aware of your requirement, but do you really need to provide access to each and every field? Think OOP. Would it make sense to have a generic object encapsulate all the data and you exchange the object instead of all the individual data?

Imagine a scenario where you got an application where individual users are mapped to say a list of data folders created by the application. For various reasons, the user is allowed access to only those files owned by him.
On the UI, I would have a login screen with fields for username and password. After the user clicks submit, I would wrap these two parameters inside a user object
and pass the object to the server side for authentication. On successful authentication the server would return to the UI a similar user object, which is now populated with a list of all the folders owned by the user. On the client I would flip the UI and now display say a list of all the folders. To populate the table, I can use the information available inside the user object.

Does this make sense?


[How to ask questions] [Donate a pint, save a life!] [Onff-turn it on!]
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
in first place thank you for your answer
Maneesh Godbole wrote:
in this refactoring (and perhaps due to my inexperience) my layouts end up with lots of nested panels

Why do you feel this is bad? In my experience, having nested panels is easier to understand as well as maintain as compared to having one single container with lots of child components added directly. Relax. You are doing good.


I'm feeling quite confortable with this approach; Good to know

Maneesh Godbole wrote: For buttons, except in cases where I needed to enable/disable them (e.g. for authentication purposes) you rarely required to access them directly. Most of the times the actionPerformed defined in their corresponding action classes does the trick.


I do need; I have all these text fields and they are multipurpose: either get populated and editable (editButton should be enabled) either they are cleared so that the user creates a new record (clear Button enabled, editButton disabled, and so on)

Maneesh Godbole wrote: For rest of the fields, one would usually define them as instance variables. Depending on the requirement, you would define the getter/setters. e.g. if you got a password field, a get/set password is all you require from outside the class. These methods in turn would access the specific fields/components.


When you mean outside the class - and that points directly to my initial question - you mean outside the class that defines the panel where they are, or, instead, the class that encloses all the subpanels?

Maneesh Godbole wrote: I am not aware of your requirement, but do you really need to provide access to each and every field?


After all I do have to populate these textfields, combos, tables and so on, so I need to have an easy access to all those components (this application is a kind of a enhanced personal note book, where I take and display my notes, perform some calculations and display some charts)

Maneesh Godbole wrote: Think OOP.


i like the concept of OO, though I might be a poor performer

forgive me expanding a bit on this subject, but I want to take this oportunity to give a brief idea on how I designed my app:
I have 3 layers, so to speak:
- a (dumb) UI layer
- a persistence layer that knows (almost) anything about all the rest
- a mixed layer which is composed by several objects
in this layer I have objects that just perform some math calculations
others that just take care of listenning stuff
others that talk to persistence layer
and so on
so, to me, this is object oriented, though I would very much appreciate any comments on this arquitecture
Maneesh Godbole wrote: Would it make sense to have a generic object encapsulate all the data and you exchange the object instead of all the individual data?

I'm sorry but I don't understand what you mean when you say "exchange"...

anyway when I want to populate the user interface I do it with data retrieved from a resultset

Maneesh Godbole wrote: Imagine a scenario where you got an application where individual users are mapped to say a list of data folders created by the application. For various reasons, the user is allowed access to only those files owned by him.
On the UI, I would have a login screen with fields for username and password. After the user clicks submit, I would wrap these two parameters inside a user object
and pass the object to the server side for authentication. On successful authentication the server would return to the UI a similar user object, which is now populated with a list of all the folders owned by the user. On the client I would flip the UI and now display say a list of all the folders. To populate the table, I can use the information available inside the user object.

Does this make sense?


Yes, a lot, I guess: you filter the info for each user
in my case this application has just one user (me)
so going back to my original question, what you recomend:
- every sub panel has a public getXXX()
- only every panel directly added to tabbedPane has a public getXXX()
- having public getXXX() just in the main panel (the one that has the tabbedPane)?
i insist on this because i just tested reaching this button and wasnt that easy... , so i can imagine for all the other components
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Advice on refactoring
 
Similar Threads
General Java design question
Layout three GWT panels Horizontally
JScrollPane Frustrations
Help sorting out what combination of layouts will provide the result I need
Using GridBagLayout in Swing