A Factory with a Twist
Gumbie uses the factory pattern as described by the Gang of Four (Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma et al., Addison-Wesley 1994; ISBN 0-201-63361-2) — but with one crucial twist. Ordinarily, an object receives its factory as a parameter of its constructor. Gumbie, on the other hand, keeps its factory in a module called "Config." This module is initially empty, and the module that chooses the factory imports Config and assigns the factory to Config as a module variable, Config.factory. The other modules of Gumbie import Config and work with Config.factory.
I've done this for two reasons: First, once the factory has been placed in Config.factory, it is easily accessible for all modules that may need it, which is simpler than passing the factory as a parameter all the time. More importantly, the class MenuMaker is meant to be mixed with other classes (frames such as java.awt.Frame in particular), and the factory provides the classes to be mixed with MenuMaker. In other words, the factory determines superclasses of some Gumbie classes (see, for example, PowerFrame2.py), which would be impossible if the factory were passed to the constructor; by the time the constructor is called, the superclasses are already in place.
This design puts a Python-specific spin on the factory pattern and may be useful in other situations as well. There is, however, one drawback caused by a limitation of the current version (2.1) of Jython. When compiled with jythonc, the resulting Java bytecode won't work without the Jython compiler classes. This isn't a problem in most situations, as jythonc creates jar files containing all the necessary classes. However, web browsers such as Netscape Communicator refuse to open such files as applets because the compiler classes cause security violations.
Finn Bock, one of the developers of Jython, has indicated that future versions may remove this limitation. For the time being, I have decided to introduce two additional modules, PowerFrame.py and LayeredFrame.py, that are the same as the generic modules PowerFrame2.py and LayeredFrame2.py, except superclasses are hard coded. Applets should use the specialized modules instead of the generic ones. Although somewhat unpleasant, this solution is harmless because all code based on the specialized modules also works with the generic ones, so the two branches merge effortlessly once this limitation of Jython is gone.
— P.B.
