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 6/27/06, Mathieu SUEN <mathk.sue at gmail.com> wrote:
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060627/84ee69d0/attachment.htm