diva.canvas: Design re-review, June 22nd, 1998
John Reekie, 20 Jul 2001

diva.canvas: Design re-review, June 22nd, 1998

• Preliminary notes
• Identified defect
• Related issues
• Concluding notes

Preliminary notes

Re-review called by John Reekie for the top-level architecture of diva.canvas, redesigned to deal with problems notes in the last review with coordinate systems and Swing compatibility. There was only one reviewer (Neil Smyth) but sometimes you just have to work with what you can get...

The reviewed file is tagged version-0-3 in the diva repository.

• Moderator: nsmyth
• Scribe: johnr
• Author: johnr
• Reader: johnr
• Reviewers: none

Review started: 4.10 PM
Review ended: 4:50 PM

Identified defects

1. CanvasPane would be simpler if it just kept an order list of layers, instead of the current non-contiguous set of integers.

   It would be! I made CanvasPane into an abstract class, so that subclasses are required to provide the storage and access methods for layers. This is better anyway, I think: rather than having a complicated API that allow clients to manipulate layers in every way possible, just let them define how they want the layers and provide access to them. In addition, I defined the class BasicCanvasPane, which contains just a simple linear list of layers with a couple of access methods.

2. CanvasLayer needs to be made consistent with CanvasPane in the paint() and repaint() sets of methods.

   Done.

3. FigureContainer.children() and ZList.overlapping() each need to be made into two iterator methods, instead of returning an array.

   I created the following methods:

   Iterator FigureContainer.figures ()
   Iterator FigureContainer.figuresFromFront ()
   Iterator ZList.figuresOverlapping (Rectangle2D region)
   Iterator ZList.figuresOverlappingFromFront (Rectangle2D region)
   

   Note the change from "children" to "figures," which I think is more consistent with the meaning of the methods.

4. CanvasPane.addLayer(): order of arguments is wrong.

   Fixed.

5. None of the methods in FigureContainer or ZList define the behaviour in anomolous cases eg adding a figure that already exists, and so on.

   Decided and documented.

Related issues

none

Concluding notes

Rework is still being done following the previous review. In particular, the class diagrams need work.

Now that I've starting writing this code, I am converting the specification into the programmer's guide. It's too tedious keeping the spec in sync with the code, as there are lots of small changes, so refer to the API javadocs to verify the above changes.