Once and Only Once

When a piece of behavior or information is represented in more than one place in a software architecture, there is a really good chance that, eventually, it will get out of date in one of those places. In the short term, each time that behavior (and I mean this in the general sense, not just a piece of code copied from one place to another, but any information) needs to be changed, you have to locate and update each copy, multiplying development costs. Following the path of least resistance, over time, it is likely that one of the representations will get out of sync with the others, causing bugs, needlessly increasing code complexity, thereby increasing future development, maintenance and support costs. NDOC and JAVADOC allow developers to embed documentation right in the code and serve as examples of tools that work in practice to help maximize the return on investment in software over its natural lifecycle by reducing information redundancy. These tools are good because they make it easier to do the right thing first. When designing and implementing software systems, searching out the redundant representation of information can seem to make a simple process needlessly more difficult. Sometimes it is subtle, sometimes not, easily dismissed as unimportant, but in my experience worth the time and effort spent to identify it and factor it out. So, next time you're tempted to cut and paste that code snippet, think about the implications, and go back and read this.

The more things change, the more they stay the same.

I have spent the past 7 months or so reacquainting myself with JAVA based development after a two year run building a .NET credit derivatives trading system in C#. Now back squarely in the JAVA world and working on a number of projects for several global trading organizations, some of my old gripes with Swing-based (and in general, JAVA-based) applications have come back to the fore. This time around I find myself motivated to use SWT for my GUI development, since, like the VM, SWT based applications are by definition more tightly coupled with the native platform so there is a better chance of producing good looking applications faster -- at least that is part of the promise of SWT over Swing.

Having read through much of the positioning statements on SWT vs. Swing readily available with a web search, I have found that one of the biggest challenges in SWT development is the lack of comprehensive, non-trivial coding examples that don't use JFace. This is completely understandable, given the relative maturity of SWT as compared with Swing. As JFace becomes more cleanly separated from Eclipse and hence more usable for standalone work this situation will improve dramatically I suspect. But for now, while I have looked into the design and implementation of JFace, for standalone development projects I am avoiding it ... for the time being.

This brings me to my point. I am working on an application framework for my own development projects, and I don't want to spend the time tweaking a Swing-based framework just to get it to look half decent. Partly too, I chose SWT to prove to myself that SWT is mature enough to use in sophisticated development efforts (other than Eclipse, mind you), or rule it out. Recently, I couldn't find a simple example that demonstrated how TreeItems could be selectively added and dynamically removed from an SWT Tree, presumably because of the following design principal of SWT:

A parent is set by passing it to the constructor of TreeItem and can't be modified from either end of the relationship. Because of the way these relationships are maintained, removing a single item from a Tree is awkward: You must call removeAll() to empty the Tree and rebuild its contents, minus the items you wish to remove. ... from SWT/JFace in Action

While this makes it easier for the implementers of the widget to ensure it's internal integrity, it makes it harder to use an SWT Tree in contexts where you dynamically want to add and remove nodes based on user control. Not impossible mind you, just harder. So, my contribution is a hopefully ever-growing list of snippets. The first example, Tree and TreeItem, creates a tree with a single root element in it, and by right-clicking, the user may insert new nodes before, after or into the selected node. The example does not allow deleting the root element, or giving it any siblings, so the first action selected must be to insert into the root node. From there, you can freely add and remove nodes.

The Tree example may be straightforwardly generalized to implement insert/remove functionality on subclasses of these SWT widgets, and thereby reuse this functionality across projects.