Software Metrics
This is a reformatted example from chapter 17.4 of:
Swing
Second Edtion
Matthew Robinson
Pavel Vorobiev
ISBN 1930110-88-X
The Chapter describes the care and feeding of Java’s JTree’s. I am not a Swing anything (expert, novice, or felllow travelor), so this reference, as well as the Java Tutorials, provides needed and valuable examples for me. And here I must digress to explain my viewpoint and disagreements with this books examples. Pst: you need not bear with me since you can just ignore this stuff and go to the code but, sigh, in a dispirited sense of inspiration I’m going to tell you “What I Think”. Send me email to express you’re vehement objections.
A tree is a very simple architectural concept. It is one step above a list, and the first data structure for which a 2 dimension representation is required. A tree has two parts:
- Mechanisms to handle the tree architecture.
- Mechanisms to handle data put into the tree.
GUI representations (Swing in this case) are somewhat more complex. They have
- Linkage to the Tree architecture.
- Linkage to the Tree data.
- Static representation of the Tree architecture and data.
- Interactive components to modify the Tree architecture and data.
And of course, since the GUI and the Tree have to act in concert, there needs be means for the GUI to access the Tree and vica-versa.
Somewhat pictorially we have:
Tree <=> GUI
| |
| |
o data o Monitor display
o User interaction
The Swing examples in Chapter 17 are not compliant with Software Metrics defining good code. Most of the code is contained in a single constructor (DirTree) Some of the variable names are awkward (a1, a2, a3 listeners for example). The architecture is shallow and does not provide a good view of functional separation and control logic, with a constructor which does most everything, and a few classes to handle things awkward to put into a constructor. Encapsulation is almost nonexistent as is information hiding and the separation of control logic from definitions. The result are examples which are needlessly difficult to read and understand and a difficulty in adding new functionality in an organized manner.
I have taken a hand at providing an overall architecture and providing some encapsulation. I have removed anonymous everything and renamed variables as required. Documentation has not been provided, this is not ‘my’ professional code, it is a means for me to understand what the example does.
I have passed global variables in constructors. This is decidedly a very bad idea. It has introduced instantiation dependencies (this class must be instantiated before that class) and the addition of mechanisms to add data to an already instantiated class because of runtime dependencies which can not be satisfied when a class is instantiated. All regretful. Sigh. Sorry. I just didn’t think.
Other than cosmetic things, I have tried to keep the original code intact and unaltered. That is, up until EditorListener.java. In the EditorStopped method the original File.rename() did not work. When I replaced it with Files.move() I also included some failure coding (“what happens if things don’t go accoring to plan”). This is in opposition to success coding (“what I expect always happens”) which is employed throughout.
The zip file contains the original code and the redone code. I hope it is more more understandable than the original. Then again, there is no guarantee that it is. Since this is a personal vision of good code I would enjoy hearing aboutthe why’s and wherefor’s of better presentation and code.