2006/6/28, stéphane ducasse <ducasse at iam.unibe.ch>:
>
> 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
>

Yes it should be very intresting
+1

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