Design Patterns in the Test of Time: Chain of Responsibility
by
Join the DZone community and get the full member experience.
Join For FreeThe chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end of this chain.
It is actually quite common to see this pattern now-a-days using events. Something like CancelEventArgs and a CancelEventHandler to handle the FormClosing event of a Form.
We use Chain of Responsibility in RavenDB in several places, like this one:
foreach (var requestResponderLazy in currentDatabase.Value.RequestResponders)
{
var requestResponder = requestResponderLazy.Value;
if (requestResponder.WillRespond(ctx))
{
var sp = Stopwatch.StartNew();
requestResponder.Respond(ctx);
sp.Stop();
ctx.Response.AddHeader("Temp-Request-Time", sp.ElapsedMilliseconds.ToString("#,# ms", CultureInfo.InvariantCulture));
return requestResponder.IsUserInterfaceRequest;
}
}Note that we have moved on the the behavioral patterns, and those tend to have withstand the test of time much better, in general.
Other places where Chain of Responsibility is used is request routing and error handling. A common approach is to also have this done by delegating, where I am handling what I can and passing on to the next object if I don’t know how to handle a request.
Recommendation: This is still a very useful pattern. One thing to note is that it is effectively an O(N) operation with respect to the number of items in the chain that you have. As usual, do not overuse, but it is a really nice pattern.
Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments