From: Robert Klemme <bob.news@...>
Date: 2003-05-14T00:14:23+09:00
Subject: Re: State Pattern Implementation


"Mauricio Fern�ndez" <batsman.geo@yahoo.com> schrieb im Newsbeitrag
news:20030513124716.GA12385@student.ei.uni-stuttgart.de...
> On Tue, May 13, 2003 at 08:11:38PM +0900, Robert Klemme wrote:
> > > > I'd like to hear what people think: is this a reasonable
> > implementation of
> > > > the state pattern?
> > >
> > > You are representing each state by a number... with the State
pattern
> > > isn't each state supposed to be represented by a class ?
> >
> > Normally, yes.  The association with a number is just for the ease of
> > keying the example in.  My main idea was to replace the state instance
by
> > a redefinition of instance methods.  Pro is, you safe an instance and
a
> > redirection; on the con side is increased code size for the class
since
> > you have to include code for all states.
> >
> > I'm curios to know whether anybody did this before.  I might be
missing
> > some grave disadvantage.
>
> Probably stupid, but all I can think of right now:
>
>  * easier to screw up things as the state is defined implicitly by the
>    singleton methods, so you could probably reach "non-valid states" (if
>    you forget to redefine one method)

Yeah, sounds reasonable.  One can forget do implement a method in a state
class but this might easier show up since the state class can be tested
separately.

>  * cannot serialize these things, i.e. cannot capture the state of the
>    object (related to the latter)

That's a major drawback IMHO - at least for applications that need to save
state.

> Finally:
>  * no clean separation between the place where you define state
>    transitions and the state methods/attributes (which can be a good or
>    bad thing depending on how you see it)

Yes, states behavior gets mangled back into the class again.  That's kind
of anti state pattern...

> OTOH, it is clever (extra points!!!! ;-), faster than delegation, and
> uses singleton methods (we love them, don't we? :)

Yes, of course! :-))

    robert