Some Stuff

This is a sketch of my understanding of Arvid's renderer design: I say 'my understanding' with good reason - a diagram can be biased, even a formal(ish) one like this, so I don't claim that this is definitive! It is interesting, anyway, as it seems to be a combination of a Composite and a Visitor pattern. The RenderingModel implements IRenderingElement (and Iterable of IRenderingElements), which is Composite. The Modules are Elements in the Visitor pattern, and the Elements are Visitors. edit: What nonsense I talk! The IRenderingElements are Elements and the  IRenderingModules are Visitors. That's better.

Sorry, but some more opaque UML diagram from the cdk.controller package. First, the Controller2DModules: Which is very simple, although the names are a bit clumsy. I would favour using a sub-package called "module" and then having "AddAtomModule", "ChangeFormalChargeModule", and so on. Doesn't really matter, as they will likely not be used very often. The other image is more complex; it shows the class that implements IChemModelRelay and how it interacts with the two current Swing event handlers. The circles represent interfaces. The MouseListener and MouseMotionListener are, of course, the interfaces from the java.awt package that are normally used by java programs. Now to figure out how to actually use all this!

One way to understand a piece of software architecture is to make a diagram out of it: Also, it's an excuse to make another diagram... Oh, and here's the version with packages:

Soooo. I have been messing around with what I've optimistically been thinking of as an 'alternative' JChemPaint renderer rather than just a botched refactoring. I started with the code by Niels Out ( blog ) and messed around with it a bit. Here is a diagram of part of where it is at: This is meant to be valid UML, but the message is the same : "Overly. Complex." The basic idea is that the parent SymbolTreeFactory handles the logic of what bonds to create, and the child factory creates a tree suitable for AWT. There's a name problem here, as "AWT" is not right for Java2D; also I'm not sure why I decided on "SymbolTree" as it's not really a tree as such. It could be, using a Composition pattern perhaps, but that seems unnecessary. Anyway, the point  of this is to make separate AWT and SWT renderers, while sharing as much code as possible. This may not be the way to do it, but it is a  way to do it.