State pattern v/s Orchestrator

Requirement

Normally in programming we encounter scenarios where we need to carry out many operations in sequence. The sequence of operations can change based on client's business requirement changes. At this point we can assume that there is no parallelism required. How do we code such a scenario efficiently?

To tackle this, either we can write everything in single function or we can split the entire operation as step functions and have another controller function calling the those in the required order. Some people who are inspired by patterns go for pattern oriented programming and most of them end up in state pattern.

Before we go further, if anybody still thinking that what is the problem in writing the code in sequence or in single function? I would suggest get better understanding about the below concepts of programming.

• Object Oriented Programming
• Single Responsibility Principle
• Re-usability
• Separation of concerns

State pattern

State pattern defines the system as discrete states of object where each state knows what are it's next  possible states. It also has mechanism for changing the state upon any event. Events can be anything such as keyboard input, UI action such as button click, a service invocation, a timer elapsed event etc...

There are defined ways and many libraries available as well which helps us to implement state pattern. Some libraries support encapsulating different states into different classes and we can connect them. But as the basic nature is one state knowing other, its very difficult to change the sequence without changing the state classes.

Below are some links which contains implementation of state pattern and libraries.

• http://www.dofactory.com/net/state-design-pattern
• http://www.codeproject.com/Articles/489136/UnderstandingplusandplusImplementingplusStateplusP - Explains problems with sequential code and state pattern
• http://www.codeproject.com/Articles/509234/The-State-Design-Pattern-vs-State-Machine - Explains we can everything with state pattern without using state machine.

State pattern v/s state machine

Now most of us will get a question in our mind. What is the difference between state pattern and state machine. As of my understanding state pattern is just another state machine implementation which is clean and dead simple. We can build state machine using iterator / yield, Windows Workflow Foundation , or more simpler stateless library.

Orchestrator / Sequencer pattern

We have seen what is state pattern. But is that suitable in the requirement mentioned at the beginning of this post?  According to the requirements the flow can change based on business requirements ie  logic in one step should not tell what is my next step . In state pattern each state should know about other state and tell the engine to go that particular step. If we use that state pattern we cannot build independent steps which can be interchangeable. In most of the cases, steps will be dependent each other. But our requirement is specifically about independent steps. So what is the alternative by honoring all the programming principles.

The solution leads towards orchestrator or sequencer pattern where we can define the sequence and just start the sequence by giving context which the steps are going to manipulate. It will take steps one by one and execute. I was not able to relate this requirement with any of the GOF design pattern, that's why I had to use orchestrator. Template pattern in GOF is somewhat similar. But in that we could see implementation class contains all the operation methods which seems we are violating the SRP in SOLID. 

What is Orchestrator pattern requirement

• It needs to provide an abstraction (preferably interface) to create concrete step implementation classes.
• Support for receiving data context into the steps.
• It should be having support for defining / sequencing our steps.
• A StartExecution method
• Prefer 2 modes of execution
• Pipe line mode - Returned value of one step should be feed as input of next step
• Normal - All the execution methods in steps will get the context passed via StartExecution method.

A sample implementation is in progress. Hopefully I can share in next post.

Difference between state pattern and orchestrator (Sequencer)

Summarizing the differences between state pattern and sequencer. State pattern requires one state to know other. If the logic changes we need to modify the concrete state classes. In orchestrator the states/steps are independent.