Tooled Composite Design Pattern Andy Bulka Austhink Software [email_address]

By GOF author John Vlissides http://www.research.ibm.com/designpatterns/pubs/ph-sep99.pdf

The Problem

“direct manipulation” metaphor. How do you represent shapes? How do you represent tools? How do tools and shapes interact? How do you enhance the editor with new shapes and tools?

How do you represent shapes?

How do you represent tools?

How do tools and shapes interact?

How do you enhance the editor with new shapes and tools?

Representing shapes COMPOSITE – design pattern

Representing “Tools” usually a palette of tools editor’s behavior changes with the current tool E.g. when drawing tool is active we create shapes; E.g. when the selection tool is active we select shapes

usually a palette of tools

editor’s behavior changes with the current tool

E.g. when drawing tool is active we create shapes;

E.g. when the selection tool is active we select shapes

Representing “Tools” STATE – design pattern

How tools and shapes interact How a tool interacts with each shape is usually different m x n possible interactions between m tools and n shapes. How do we manage and organise this complexity? Answer -> with the visitor pattern

How a tool interacts with each shape is usually different

m x n possible interactions between m tools and n shapes.

How do we manage and organise this complexity?

Answer -> with the visitor pattern

Visitor Shapes don’t have tool knowledge – tools do all the work. Shapes just implement AcceptVisitor(v) and then do a v.VisitShape() or v.VisitEdge() or whatever they themselves are. Each tool has a VisitShape VisitEdge VisitShapeRhEdgeZone method that gets triggered in this way.

Shapes don’t have tool knowledge – tools do all the work. Shapes just implement AcceptVisitor(v) and then do a v.VisitShape() or v.VisitEdge() or whatever they themselves are.

Each tool has a VisitShape VisitEdge VisitShapeRhEdgeZone method that gets triggered in this way.

Example Sequence Start in Hover Tool All mouseMove events go to Hover tool As hover over shapes/edges you ask what is under me and change cursor. You “visit” the shape and change cursor accordingly ToolHover -------------- VisitShape() cursor = HAND VisitEdge() cursor = ARROW

Start in Hover Tool

All mouseMove events go to Hover tool

As hover over shapes/edges you ask what is under me and change cursor. You “visit” the shape and change cursor accordingly

Example Sequence continued User Left Clicks HoverTool.OnLeftClick sees that you are over a resize zone shape, so switches to the Resize tool Zones (e.g. resize zone) within shapes are also ‘shapes’ Resize tool.OnMouseMove resizes the shape you are on. Repeatedly (as MouseMove events arrive). Resize tool.OnMouseUp switches back to the hover tool.

User Left Clicks

HoverTool.OnLeftClick sees that you are over a resize zone shape, so switches to the Resize tool Zones (e.g. resize zone) within shapes are also ‘shapes’

Resize tool.OnMouseMove resizes the shape you are on. Repeatedly (as MouseMove events arrive).

Resize tool.OnMouseUp switches back to the hover tool.

RTTI as alternative to Visitor Have each tool use RTTI (runtime type info) to see what the type of the shape is and do something. Thus instead of each tool with numerous VisitSOMETHING() method, just have a single Visit() method with an if statement based on rtti inside. ToolHover -------------- Visit() if target == Shape // use of RTTI … else if target == Edge ….. ToolHover -------------- VisitShape() … VisitEdge() ...

Have each tool use RTTI (runtime type info) to see what the type of the shape is and do something.

Thus instead of each tool with numerous VisitSOMETHING() method, just have a single Visit() method with an if statement based on rtti inside.

RTTI as alternative to Visitor When visitor was invented double dispatch was the only way to get around the lack of RTTI in C++ RTTI approach is simpler than visitor Easier to reuse and specialise tools since don’t have to modify visitor class every time add new shape – just subclass a tool and use RTTI Also - instead of RTTI just have each tool return an enum or string from its GetMyType() method or something similar – avoids overhead (if any) of RTTI and is under programmers complete control.

When visitor was invented double dispatch was the only way to get around the lack of RTTI in C++

RTTI approach is simpler than visitor

Easier to reuse and specialise tools since don’t have to modify visitor class every time add new shape – just subclass a tool and use RTTI

Also - instead of RTTI just have each tool return an enum or string from its GetMyType() method or something similar – avoids overhead (if any) of RTTI and is under programmers complete control.

Events Funnel all events through to the current tool . Each tool has custom handling for all the gui events e.g. mouseDown, mouseClick, mouseMove etc. Classic STATE pattern, passing through method invocations to the current state object

Funnel all events through to the current tool .

Each tool has custom handling for all the gui events e.g. mouseDown, mouseClick, mouseMove etc.

Event Handling MouseUp might trigger exiting a tool and reverting to another tool e.g. back to Hover. State pattern – each state knows when to switch to another state – OR – outer class e.g. canvas knows

MouseUp might trigger exiting a tool and reverting to another tool e.g. back to Hover.

State pattern – each state knows when to switch to another state – OR – outer class e.g. canvas knows

State Pattern – switching state Notice calls to “SetTool”

Prototype Pattern Use for creation tool Create a copy of an instance of an object Could create a new instance rather than prototype – depends on how complex the prototypical object is

Use for creation tool

Create a copy of an instance of an object

Could create a new instance rather than prototype – depends on how complex the prototypical object is

Command Pattern Hook in command manager for undo/redo We use tool to generate a command and then run the command, which redoes the gui action, except through “official channels” 

Hook in command manager for undo/redo

We use tool to generate a command and then run the command, which redoes the gui action, except through “official channels” 

Final Pattern

Reflections Classic approach -> visitor. Practical approach -> use RTTI (or equivalent e.g. have each shape return a shapeType enum) for better comprehensibility. Classic approach -> 3D table of possibilities, with events, shapes, tools on each axis. Practical approach -> table too sparse and complex, so just code for the cases you want.

Classic approach -> visitor. Practical approach -> use RTTI (or equivalent e.g. have each shape return a shapeType enum) for better comprehensibility.

Classic approach -> 3D table of possibilities, with events, shapes, tools on each axis. Practical approach -> table too sparse and complex, so just code for the cases you want.

Reflections Classic approach -> some blend of visitShape() / visitEdge() etc methods and mouse event methods, within each tool Practical approach -> Skip most of the visit methods and do the logic in the mouse handling methods. Generalise the mouse handling into one event (mouseAction) and use if statements to catch the situations of interest. You know what the current shape is by having a pointer to it (set up for you by the tool or something).

Classic approach -> some blend of visitShape() / visitEdge() etc methods and mouse event methods, within each tool Practical approach -> Skip most of the visit methods and do the logic in the mouse handling methods. Generalise the mouse handling into one event (mouseAction) and use if statements to catch the situations of interest. You know what the current shape is by having a pointer to it (set up for you by the tool or something).