Workflow with state pattern

Hi,

I was wondering if it make sens to use state pattern for a worklow.

I have to implement a system to let user to place an order.

Also if you have some small stuff about it  I will be happy to know them. :-)

Thanks

Cheers,
Math

The state pattern is only useful for a small number of states, because has several "scaling" problems:
- Who defines the transitions?
- Who implements the behavior of each state?

Usually, the "Context" (the GoF book calls "Context" to the object that delegates messages to each "Concrete State") defines the transitions between states and defines the specific implementation of each state. So the Concrete State only dispatches messages to the Context and nothing more. (yes nothing stops you form doing more things in each Concrete State, but I think that is not convenient).

So if you use a state pattern to model a workflow, you may have the following consequences:
-A static workflow difficult to understand => maintain and extend
-A big Context object with a lot of messages

I think that is better to model the workflow graph, with transitions and activities.

At Mercap we have done that, with very positive results: our system is based on a embed workflow that runs on GemStone and even the menu options triggers workflow processes (ie.  "Exit" option triggers the "Exit Workflow" :) ), so we can adapt the workflow for each client business. (sorry that I can't share the implementation, I think that would be nice to open-source the workflow framework... but that doesn't depends on me).

As a final comment, in your order application the "state" of the order is independent of the workflow, ie: you can have different states for each order: pending, processed, delivered. And a workflow with a lot of activities to pass an order from pending to processed. So if you have a embed workflow you have to model the different states of the order too.
Also think in the behavior that changes for each state, for example in a PrinterSpoolingSystem you can have different collections (or queues) for "pending" and "in-progress" jobs, without having to implement a state of pending/in-progress for each PrintJob object.

Regards,
Diego.-

On 27 juin 06, at 20:20, Diego Fernandez wrote:

but could you at least share the design :)

Stef

2006/6/28, stéphane ducasse <[hidden email]>:
Yes it should be very intresting
+1