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
|