Is state pattern a wise architecture for a diagram application?

Question

I'm designing a vector drawing app.

I need to implemente copy and paste, shapes insertion, deletion and transforming while still being capable of including new tools with easy in the future.

The way I think about it, this is a finite state machine, so i thought about a State Pattern. The stage behaves differently based on it internal state. Each state would be a tool.

var stage = new StageManager();

var insert = new InsertTool();
var copy = new CopyTool();
var paste = new PasteTool();
var select = new SelectTool();

stage.registerTool(insert);
stage.registerTool(copy);
stage.registerTool(paste);
stage.registerTool(select);

If, say, user just pasted a shape, StageManager transitions to selection mode (SelectTool).

onMouseUp(event){
    this.stageManager.addShapes(this.stageManager.clipboard.getAll());

    // Just pasted, transition to selectionTool
    this.stageManager.chooseTool('selection-tool');
}

// From now on, stage behaves like a selectionTool.

Is that a wise architecture for a diagram app?

Answer 1

I think it's a good architecture to begin with. There's a way for states to make a transition without knowing too much about each other. They just need to know the interface and a key.

I'll assume your language supports interfaces and that all tools implement the tool interface.

• Create global constants, one for each state.
• When you register the states do it in a map/dictionary collection. You put the tool and its "ID" in the map. That way you can retrieve them from the map using that key (the corresponding constant).
• Each tool have a list of possible next states, which could have zero, one or more possible "next states" it can transition to. BUT that list doesn't contain the tools themselves but their key.
• Then inside the implementation of each tool you can decide which tool to transition to and get them from the registry using their key.

This answer to another question shows working code in Java of a state machine where each state transitions to the most appropiate "next state". The example is about a car whose behavior is modeled as a finite state machine. In that example the states are inner classes of the class that contains them (as opossed to injected), and thus they have access to the collection of states (equivalent to the collection of tools you have in ToolManager when you register tools. But you can find a way to do the same thing without the tools (which are states). One way is injecting a callback into the tools when you register them so that they can get the instance of the tool they need to transition to from the collection of registered tools of the manager by the corresponding key.

If you decide the transitions in the manager, you will end up with a if-then-else or switch-case mess.

At the moment of registering you can also inject a context object (singletons) into the tools so they have access to what color is selected, etc.

Also you would like to implement the command pattern in order to support undo operations.