Chain of responsibility vs Finite State Machine - differences

Question

So as I am a bit of electrician and programmer I thought I knew FSM design pattern very well. It is:

• We have set of Nodes,
• Each Node knows, what to do, when program is in this node,
• Each Node contains references to another chosen nodes, and knows under what condition, should he proceed to the chosen one.
• On event or after processing a Node, Node proceeds to the next chosen Node

I thought, that it was quite clear to me. Although recently, when I was implementing a State Machine one person told me, that it is in fact a bit modified Chain of responsibility (not sure if he was correct) and , what I did/had was:

• Set of Nodes (which did not represented a linear or tree structure)
• Nodes had objects, that knew under which condition they should jump to which Node
• Each Node had it's own context of processing (some parts of contexts were shared between Nodes).

Unfortunatelly I am afraid, that due to legal issues I am not allowed to paste a class diagram here.

---

On the other hand we have got chain of responsibility, which I would (as I understand) define in a following way, that is:

• We have got some ItemToProcess Interface,
• We have got some Node Interface,
• Node has a reference to only one next Node,
• Each Node processes ItemToProcess and forwards processed one to the nextNode

So as far as I understand:

• We use Chain Of Responsibility, where we want One item to be processed (or at least tried to be processed) by each node
• Chain of responsibility represents sequential and constant execution of processes
• We use StateMachine to represent graphs
• We use StateMachine to perform computations, which order or kinds of computations may vary depending on some events.

I would like to ask you to confirm my understanding of those design patterns or tell me where I am making mistake in understanding.

Answer 1

I'll complement the other answer by saying that design patterns also consider making software easily extendable.

Chain of responsibility has the advantage of being able to code new ConcreteHandler classes to extend your processing functionalities, without the Client class having to be modified.

The code the builds the chain, however, must be modified to add the new handler as an object:

State is not as flexible if you want to add new concrete states. The GoF book shows this diagram:

What's not obvious (read more in this answer) is that Handle() events are coupled to another ConcreteState class (i.e., the next state). So, coding a new ConcreteState could require changes in some or all of the existing ConcreteState classes.

It's perhaps not as easy to add new states in the State pattern as it is to add new handlers in the Chain of Responsibility pattern.

Answer 2

Your understanding is correct.

I would add that the Nodes in a FSM are different states. When you switch to a different node, you change state. You may call the same state/node several consecutive times.

The chain of responsibility does not have different states. As you said, each node in the chain tries to process an object and if a node successfully processes the object, then usually the chain halts.

Common uses for chain of responsiblity are lookups for figuring out what Handler to use for a given input such as file types or extensions or finding items in a classpath or resource locator. You can think of those types of operations as :

[Node 1]

"-Do you know what this is?"
-No
[Node 2]
"-Do you know what this is?"
-No
[Node 3]
"-Do you know what this is?"
-Yes!

done