email article printer friendly more resources

Hunting the Unicorn
A little trickery overcomes adapting diverse object classes to a mutual framework when building custom tools
by Daniel F. Savarese

March 30, 2006

Over time, past-conquered programming challenges have a habit of reincarnating themselves. They look slightly different, yet underneath their skins beat the hearts of beasts felled previously by tried and true daggers of design. You recognize the weapons you must bring to bear as you rejoin a battle best avoided. Combating the fiends consumes precious time even though your victory is certain.

Patterns of design are the weapons we apply to recurring programming challenges, and reimplementing those patterns in similar situations is the combat we endure. By implementing generic code that can be reused in many situations, we can dispatch our enemies quickly or avoid combat altogether. I liken the quest for a single implementation that can be applied in many instances to a hunt for the elusive unicorn. The animal may be subdued only through trickery. Once captured, its horn will cure all poisons.

I’ve been troubled of late by the little tools I build to perform quick tests or aid in debugging. It seems I build the same sorts of tools for different projects, but can’t use the same code because of implementation-level differences. The functions of the tools are identical, yet I have to spin cycles recreating them. With the aid of open source software libraries, this sort of tool building takes far less time than it might otherwise. For example, I’ve used the Jakarta Commons BeanUtils library many times to convert text to class instances and back again. The practical goal of reusable software is not elegance of design, but the saving of time.

Nevertheless, it takes time to save time. You’ve got to put in the hours to figure out how to generalize the solution to one problem so that it can be applied to many related problems. When you build a simple development aid quickly, you don’t take the time to generalize its implementation. Your primary objective is to get back to writing the main project’s software, not to dilly dally with development support software. That’s why the same tools have to be built time and again for new projects.

Enough, Already
With that in mind, I’d like to take the time to step through the process of generalizing a development aid I’ve had to implement two times. When the situation cropped up a third time, I said, “enough is enough!” and decided to implement the tool in a generic and reusable fashion. A couple of years ago I was writing self-reconfiguring middleware. The system was built using Java Management Extensions (JMX) MBeans to facilitate introspection and external management. As part of the development process, I needed to be able to examine and modify live configurations, individual object instances, and other run-time state. To do this work, I wrote a simple configuration tool that included a component that could dynamically assemble a graphical user interface (GUI) exposing the operations and attributes of an MBean.

Lo and behold, not long afterward, I had the need for a similar tool for working with JavaBeans. The implementation was nearly identical, but it relied on the BeanInfo class and the java.beans package instead of MBeanInfo and the javax.management package. I discussed a simple version of this tool in a previous column (“Introspective JavaBeans,” Java Pro, July 2004). Most recently, I needed to dynamically construct a user interface for accessing arbitrary Web services based on a WSDL descriptor. That’s when I decided to stop and build a small framework to simplify this sort of dynamic inspection of objects. Even though each tool had slightly different requirements, they all needed a Swing component that could discover and expose the public operations and attributes of an object.

Before continuing, I’ll mention that the code for the Swing component, which I’ve named ObjectPanel, is very similar to that for BeanPanel in my earlier column. Therefore, I will present only the key abstraction (see Listing 1) for the generic version of the software and an example (see Listing 2) of how to use that abstraction to build a generic tool (see Figure 1). (See Resources for the complete source code download under the Apache License 2.0).