The initial versions of the code used an array collection of instances of Nodes - this is fine if I'm only ever going to display one type of data, but to make the code a lot more flexible and scalable, I now pass it an array collection of objects that conform to my INode interface. The interface contains all the methods that the node based interface requires to render.

So, I've created a new class that sits outside the presentation package called CalculatorNode which implements INode.

To further decouple the interface from the data, I inject the node renderer and the detail form into the UI. These two classes implement my INodeRenderer interface and are defined in the DomainModel class (a small caveat - in this proof of concept release, I've still got the node widget's height and width hard coded).

A double check through the source code and there are no references to any of the calculator classes in the presentation package! All the logic for calculating the output is handled in the CalculatorNode value object which is a style of domain driven development I quite like. However, to conform to a more MVC style, this logic should really live in a command.

The application lives here and the full source is available here. You can add and delete nodes, change them from fixed numbers to operators. The user interaction for creating relationships needs to be changed to allow dragging between nodes, but the checkboxes work OK. If a relationship is unused it's renderered in grey (for example if you pass more that one number to the square root function, only the first number is considered).

Of course, a calculator is only the beginning. I've been thinking about a CAD type application for this code where each node represents a shape and those shapes can be overlaid with different blend modes.

Finally, I couldn't get SharedObject to play nicely, so that code is commented out. Any changes you do will be lost with each new session.