[Quest] Design patterns for switchable Behaviors: Automata & the Strategy pattern

[gregsn]

There are behaviors that are too complex to be modeled just with one patch:

• dataflow oriented patterns like FlipFlops, Toggles, and Switches somehow weren't readable anymore. The logic got too complicated with the non-complicated nodes. All of them come with their state and understanding the interplay between those made it so hard.
• you tried to remodel it and came up with several properties that together model all the different states that your system can be in. You added different instance operations that read and write those properties. But now you still have to build the logic when to call what and you have to understand which properties you have to set/reset to enter some clean/consistent system state.

In these situations, it can be easier to think in system states, embrace them, and make them first-class. This is what an Automaton does. You define system states, give them names, and try to figure out how to get from "start" to "done".

Thinking in these states can make you focus on one thing at a time, which suddenly makes your system more readable/approachable/writable/debuggable. Now after scribbling your different modes the big question arises on how to patch systems like this with VL.

There are different approaches for working with automata from within vvvv beta. But they all come with the idea that you

• build up the automata

  • look down onto an automaton
  • describe the automaton in a descriptive manner (textually or visually)

• bind to the automata

  • feed data: trigger transitions via setting some boolean flags
  • retrieve data: react on the current state of the automaton

Examples:

• the old school Automata node in vvvv beta
• https://vvvv.org/contribution/automata-ui
• https://discourse.vvvv.org/t/vl-automata/17045/7
• https://discourse.vvvv.org/t/vl-workflowfoundation/17055
  • more info: windows-workflow-foundation/state-machine-workflows

In VL however, another option arises, which might feel much more natural (TBD)

• don't look down onto the automata
• don't check for the automata from outside
• patch each state, and focus on each state at a time
• somehow tell the automata to switch to a new state from within a state patch
• benefit from some automata infrastructure and design pattern, but
• in essence: build up the automata by building/focussing on mode/state patches that imperatively activate each other

[tebjan]

for reference: https://github.com/danielgerlag/workflow-core

it allows building workflows with LINQ-like fluent programming and includes state handling:

public class MyData
{
    public string Email { get; set; }
    public string Password { get; set; }
    public string UserId { get; set; }
}

public class MyWorkflow : IWorkflow
{
    public void Build(IWorkflowBuilder<MyData> builder)
    {    
        builder
            .StartWith<CreateUser>()
                .Input(step => step.Email, data => data.Email)
                .Input(step => step.Password, data => data.Password)
                .Output(data => data.UserId, step => step.UserId)
           .Then<SendConfirmationEmail>()
               .WaitFor("confirmation", data => data.UserId)
           .Then<UpdateUser>()
               .Input(step => step.UserId, data => data.UserId);
    }
}

also this one, it is cross-platform and can read Microsoft workflow files: https://github.com/UiPath-Open/corewf