http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I love this pattern and I use it somewhat frequently. Like any tool that gets used often enough, the chance arises that you can misuse it. As a cautionary tale to those who come after, here's where I most recently went wrong. I used this in place of something that would be better serviced as a state machine. It ended up being really complex with either requiring too many links in the chain, or "CanHandle" checks being way too long. I'm sure there's other ways to misuse this pattern (just like every pattern) but there was mine.http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment11http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment11Fri, 30 Nov 2012 14:13:45 GMTI have used this pattern in one of my project.. and I must say that it is savior where ever it fits good. By the way, I used it when calculation various SLAs for a task.http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment10http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment10Tue, 27 Nov 2012 11:14:34 GMTI'm with Mystical. A good example of chain-of-responsibility pattern is interceptors in Castle. Each interceptor has a reference to an IInvocation (which encapsulates the next interceptor in the line), thus allowing each interceptor to pass part of its responsibility to the next node in the chain, or even to terminate the chain altogether. The given example on this post does not allow that.http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment9http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment9Mon, 19 Nov 2012 15:54:53 GMTAyende - Just noticed your reply "Mystical, Does it matter if you call each other or it is a loop? It is the same basic principal." seems you posted it on the ASP.NET Caching post instead of this one. My point was that there is no "chain" here, none of the RequestResponder instances know about their successor (the responder that they would call if they can't handle the input themselves).http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment8http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment8Sun, 18 Nov 2012 11:34:12 GMTAyende - I'm thinking of a public API here where if you have a method that can throw an exception if a certain condition is not met, then having a method which will test that the condition is met before calling the other method is a good idea (as in the File.Exists, File.Read example). You are giving the caller the ability to avoid an exception which is a good thing! If it's all internal code and you can guarantee the behaviour of the caller then maybe it's unnecessary but I would think that relying on the caller to behave in a specific way without enforcing it is a dangerous assumption even for internal code if you have multiple people using it who may not be familiar with the intricacies of the API!http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment7http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment7Sun, 18 Nov 2012 11:25:42 GMTMystical, Why on earth do I need to call WillRespond twice? It is already checked by the calling code. Doing double checks like that is pretty useless, you need to trust your callers, especially when they are the infrastructure.http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment6http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment6Sat, 17 Nov 2012 17:41:24 GMTRangoric - It's a good practice to have the bool check in addition to the method, but if you were implementing this, Respond should still call WillRespond and throw an exception if it can't (just like File.Exists and File.Read)http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment5http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment5Sat, 17 Nov 2012 00:33:35 GMTSame question as Mystical. Not sure if this is Chain of responsibilityhttp://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment4http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment4Fri, 16 Nov 2012 20:51:52 GMTDoes that code fully qualify as chain of responsibility? I thought the pattern was for the first object to decide whether it can act and then forward the call to the next object?http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment3http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment3Fri, 16 Nov 2012 17:47:23 GMTI like the separate methods on the class/interface for Will Response and Respond. It avoids having a check condition at the start of respond, and also makes sure that the names on the methods encompass all that the method will do. It also makes the unit tests nicer.http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment2http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment2Fri, 16 Nov 2012 16:01:29 GMTAnd you might want to merge WillRespond and Respond into one call so that the responder class has an opportunity to avoid redundant computations.http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment1http://ayende.com/159841/design-patterns-in-the-test-of-time-chain-of-responsibility#comment1Fri, 16 Nov 2012 14:44:26 GMT