Which design patterns for my FSM?

Discussion in 'C++' started by LarryTheSoftwareGuy@hotmail.com, Jul 18, 2007.

  1. Guest

    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
     
    , Jul 18, 2007
    #1
    1. Advertising

  2. wrote:
    > 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
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jul 19, 2007
    #2
    1. Advertising

  3. On Jul 18, 4:21 pm, wrote:
    > 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.
     
    Zachary Turner, Jul 19, 2007
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jake

    Which FSM State?

    Jake, Oct 25, 2004, in forum: VHDL
    Replies:
    0
    Views:
    526
  2. crichmon
    Replies:
    4
    Views:
    509
    Mabden
    Jul 7, 2004
  3. Tim Smith
    Replies:
    2
    Views:
    883
    Tim Smith
    Dec 15, 2004
  4. John
    Replies:
    0
    Views:
    629
  5. Sue

    Design entries for FSM

    Sue, Mar 14, 2008, in forum: VHDL
    Replies:
    2
    Views:
    625
    jeppe
    Mar 14, 2008
Loading...

Share This Page