Why Spaghetti is Not Tasty
Jasper Potts, Sun, gave an insightful presentation at JavaOne 2007 on Why Spaghetti is Not Tasty: Architecting Full-Scale Swing Apps. Jasper started the technical session by describing the first typical architecture for a Swing application. The typical first architecture is to pass everything to everybody. The second level of abstraction in a Swing architecture is to use a singleton object that functions as the application’s service/resource finder/locator which provides lookup methods for an implementation of a given interface. For large applications, Jasper recommends using a framework and he recommends Spar. Spar is a Swing Rich Client Platform framework written by Jasper and based on his research on best practices. As Jasper described, Spar is aimed for applications with over 50K lines of code.
Jasper also talked about software modularity, of breaking up an application down into manageable chunks. Classes, packages, and libraries provide modularity in Java but Jasper, and many other people here at JavaOne, is talking about allowing for modular plugins for extending a given application. such as Eclipse’s plugins of NetBeans’ modules. There are currently a few specification regarding modularity such as OSGi and JSR 291: Dynamic Component Support for Java SE. Jasper recommended several implementations, in particularly Eclipse Equinox and Knopflerfish. Additional JSRs along these lines also include JSR 277: Java Module System and JSR 294: Improve Modularity Support in Java. These JSRs intend to provide a superpackage modular system at the language level. A module helps to separate public API from its implementation, not every class should be visible to the whole application and the visibility identifier can only do so much.
Jasper also made another recommendation that would clean up your code from inner classes. As described by Jasper, a typical Swing application uses the communication pattern typically used by listener classes, which inevitable produce huge interconnections across the whole application and a ton of inner classes littered in the source code. The solution solution recommended by Jasper is to use a message bus for Swing events. This allows the developer to set message rate limit.
The key advice given from Jasper is to break up an application into modules, limit direct coupling, and employ best practices such as plugins, IoC, and event message bus frameworks for developing your next Swing application.