Which design patterns for my FSM?

[LarryTheSoftwareGuy]

Folks,

Would love some suggestions re what design patterns to use for this
situation.

I need to create a simple FSM. A certain login scenario will behave
differently based on the following:

· 1 - 3 session traits, which are already established & stay the same
for the session duration. Trait #2 is only relevant if trait #1 is a
certain value. Trait #3 is only relevant if trait #2 is a certain
value.
· 2 different sets of states - plus a third state if the 2nd state has
a certain value.

All these traits & states are maintained locally in my program.

When I look at the possibilities in GoF & in Alexandrescu on how to
implement this, my head spins - Object factory? Abstract factory?
Functor? State pattern? Decorator? Brute force 'if' tests? All of
the above? (More than one of the above I'm sure, but I'd love some
general suggestions on which pattern would make sense where.) Thank
you verrrrry much.

Larry Kay

 

[Victor Bazarov]

Would love some suggestions re what design patterns to use for this
situation.

I need to create a simple FSM. [...]

Have you tried 'comp.software.patterns'?

V

 

[Zachary Turner]

Folks,

Would love some suggestions re what design patterns to use for this
situation.

I need to create a simple FSM. A certain login scenario will behave
differently based on the following:

· 1 - 3 session traits, which are already established & stay the same
for the session duration. Trait #2 is only relevant if trait #1 is a
certain value. Trait #3 is only relevant if trait #2 is a certain
value.
· 2 different sets of states - plus a third state if the 2nd state has
a certain value.

All these traits & states are maintained locally in my program.

When I look at the possibilities in GoF & in Alexandrescu on how to
implement this, my head spins - Object factory? Abstract factory?
Functor? State pattern? Decorator? Brute force 'if' tests? All of
the above? (More than one of the above I'm sure, but I'd love some
general suggestions on which pattern would make sense where.) Thank
you verrrrry much.

Larry Kay

Sometimes it's best not to force existing design patterns on
yourself. How about a HSM (Heierarchical State Machine). Make a
class representing each "state". These all derive from the same
abstract class, which has methods like Enter(), Leave(), and
Execute(). Each of these states has sub-states.

Then, in each subclass, you can have totally different trait
enumerations since certain traits only apply to certain states. Plus
the 3rd state can exist only as a member of the 2nd state. Etc.
Organizing state machines into heierarchies can be pretty useful in
cases like this where each state itself defines a complex set of
behavior.