Best Practices and ClientBilling example

[gihrig]

Hello All,

I am in the process of developing my first "real" app using SWT Designer. I have worked through the "SWT Client Billing" example in the Designer Guide and have this example app working with a MySQL database.

I planned to use the ClientBilling example as a model to follow in completing my app, and I'm wondering if the ClientBilling example really represents a best practices approach.

From CodePro metrics, ClientBillingUI class has:

Fields: 54
Methods: 12
Lines of code per method min: 9, max 273, avg: 63
Lines of code 1041

I get the idea from Fowler's Refactoring (Long Method and Large Class) that this code may not be well designed from a best practices viewpoint.

So, before I get too deep into studying the ClientBilling app, I would really appreciate any comments from those more familiar than I with Today's best practices regarding:

1. Any specific knowledge you have about the ClientBilling example code.
2. What these metrics say about this app in terms of good design and future maintainability.
3. General ideas and comments on refactoring code generated by SWT Designer.


Thanks, your comments are appreciated.

-Glen

[Eric Clayberg]

I planned to use the ClientBilling example as a model to follow in completing my app, and I'm wondering if the ClientBilling example really represents a best practices approach.

The ClientBilling example is intended to show off various GUI building features. It is definitley not an example of how to best structure or refactor a complex UI.

Fields: 54
Methods: 12
Lines of code per method min: 9, max 273, avg: 63
Lines of code 1041

The number of fields is very dependent on which widgets need to be programatically accessed. Designer makes this very customizable, so the number of fields you will see will vary widely based on what settings you have in place. Most text labels do not need to be fields while most text entry widgets need to be (private) fields.

The main UI method will be very long unless you either a) refactor it or b) construct the entire UI out of nested Composites. Ideally, each page of a tab group should be its own Composite. That makes it much easier to reuse pages in different combinations.

I get the idea from Fowler's Refactoring (Long Method and Large Class) that this code may not be well designed from a best practices viewpoint.

Fowler's book is primarily focused on domain code rather than GUI code. It is quite common for GUI code to have long methods containing the programatic description of the UI. You can certainly refactor those long methods into shorter ones, if you have a reason to (to reuse them in different combinations, for example). Refactoring them simply to make them shorter is usually a waste of effort.

1. Any specific knowledge you have about the ClientBilling example code.

The ClientBilling example was originaly created by the University of Manitoba in early 2004 using SWT Designer v2.0.

It was intended primarily as a relatively simple example that could be used to highlight a number of different Designer features.

2. What these metrics say about this app in terms of good design and future maintainability.

I don't think they say much of anything either way. As long as you have access to a good bi-directional GUI builder with a decent parser and decent code generation, maintainability should not be an issue.

In general, metrics designed for evaluating domain (non-GUI) code often make little sense when applied to GUI code. Trying to enforce non-GUI metrics on GUI code is usually an excercise in frustration that will yield little benefit.

3. General ideas and comments on refactoring code generated by SWT Designer.

SWT Designer is very resilient in the face of refactoring. You can easily refactor the long UI contrrutcion method into multiple smaller methods called from the main method. You can also extract composites out into their own reusable classes.

[gihrig]

Thanks for the extensive reply Eric, that is helpful.

The ClientBilling example is intended to show off various GUI building features. It is definitely not an example of how to best structure or refactor a complex UI.

Can you point me in the direction of an example or other material that shows or discusses "how to best structure or refactor a complex UI"?

Thanks again,

-Glen

[Eric Clayberg]

Can you point me in the direction of an example or other material that shows or discusses "how to best structure or refactor a complex UI"?

I am not aware of any examples like that, but you might be able to find something via a Google search.

Some general rules of thumb are:

1) Give all of your widgets useful variable names so that you can more easily identify them in your code and in the component tree of the GUI builder. Use the data field of the widget to set its name property as well (very useful, if you plan to do any record/playback GUI testing).

2) Only widgets that need to be programmatically referenced should be assigned to fields. Widgets like static Labels that are never referenced programmatically should be left as local variables. Widgets like text entry controls and checkboxes should be assigned to fields.

3) Widgets that will be visually inherited and referenced via subclasses should have a public accessor method assigned to them. Rather than exposing an entire widget via a public accessor, try to expose individual properties instead.

4) Where appropriate, decompose your complex UI into multiple, reusable Composites. For example, if you use a tabbed UI for a window, create each tab as a separate Composite class.

5) Avoid using custom fonts and colors. It is always best to use the platform defaults so that you can take advantage of platforms themes and better respect platform look and feel standards.

6) Where possible, use layout managers like GridLayout that automatically adjust to different screen resolutions and default font sizes. Never use absolute/null layout and be very careful using complex layouts like FormLayout. If you do use FormLayout, think carefully about widget attachments.

7) Extract all of your hard coded strings into resource bundles. This will make it much easier to internationalize your application later on. Some layout managers (like GridLayout) are much friendlier to i18n than others.