gihrig wrote: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.
gihrig wrote:Fields: 54
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.
gihrig wrote: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.
gihrig wrote: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.
gihrig wrote: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.
gihrig wrote: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.