Feb 20, 2011
The intent behind Chain Of Responsibility is to avoid coupling the sender of the request to the receiver, giving more than one object the opportunity to handle the request. This process of delegation appears quite naturally in the real world where there is one interface for the customer to go through.
sender -> Receiver 1 -> Receiver 2 -> Receiver n
Some of the characteristics of CoR pattern. The sender is aware of only one receiver. Each receiver is only aware of the next receiver. The sender does not know who received the message. Receivers process the message or send it down in the chain. The first receiver to handle the message terminates the chain and the order of the receiver list matters.
One example could be a bank, where an application that you send in to the bank branch may be handled by one particular department. The document may travel through various chains (dept) until it is processed by any receiver in the chain or the end of chain is reached.
One more example is of a document approval process (1 level). The document passes through various approver until it is approved by any one in the chain or the last chain element is reached.
Also, you can think about implementing an exception logging strategy (if you have specific need). The receiver of the exception object based on success to handle the exception may pass on to next element in the chain.
And there could be more similar scenarios as well.
Hope this helps.
Mar 28, 2011
A very nice example of practical CoR pattern usage are the client and server channel sinks in .NET Remoting. The client message is sent to be processed by the first receiver (sink) which then pushes the message further to the next one and so on. Each sink manipulates the message, for example it can apply binary formatting to the message or encrypt it before sending further. The last sink sends the message to the server where its own channel sinks handle it (ie deserialization, decryption etc). Hope this was helpful.