State Machine State identity

State Identity

State is uniquely represented within State Machine by string name. That rule applies to all States, defined both styles - lambda and typed. Both definition styles can interact freely, but it is important for States to be referred to (as Transition targets) by a proper name.

Important!

If you are using multiple classes that are implementing different parts of State's logic, you must remember which one is actually representing the State - the one used in AddState<>() method. Classes referenced in AddOnEntry<>() / AddOnExit<>() methods calls are not considered States that can be referred as Transition targets.

In lambda-style definition, State name is given explicitly. In typed-style definition, State class' full name is used as State name by default. This can be overriden by using explicit name for typed States:

    public class TypedState : IState
    { }

    public class StringNamedState : IState
    { }

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddState<TypedState>(b => b
        .AddDefaultTransition("stringNamed")
    )

    // this State is identified as "stringNamed", so this string name must be used in above Transition
    .AddState<StringNamedState>("stringNamed")

Referencing typed States by string names

Sometimes it may become handy to refer to typed States by string. In such cases, following technique should be used:

    public class TypedState : IState
    { }

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddState("lambdaState", b => b

        // to obtain name that identifies TypedState, State<T>.Name should be used
        .AddDefaultTransition(State<TypedState>.Name)

        // ...this is possible also for State types available as value
        .AddDefaultTransition(State.GetName(typeof(TypedState)))
    )
    .AddState<TypedState>()