Workflow with state pattern

stéphane ducasse ducasse at iam.unibe.ch
Wed Jun 28 08:09:19 UTC 2006


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

> 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).

but could you at least share the design :)

Stef

>
> 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
>
>
>




More information about the Squeak-dev mailing list