Talk:Chain-of-responsibility pattern

Problem statement needed

Design patterns are general reusable solutions to a commonly occurring problem in software design. This article doesn't describe the problem the pattern aplies to. --89.155.228.227 (talk) 16:11, 1 March 2009 (UTC)

Pattern Application

Would appreciate an example in which applying this pattern resolves a design flaw... Thanks -- User:Euyyn

Is the example correct?

I think the output is not correct. "Writing to stdout:" should be "Writing to debug output:", or vice versa. But in this state I think the output does not match the Java source. - Regards Carsten —Preceding unsigned comment added by 80.144.237.11 (talk) 12:48, 31 July 2008 (UTC)

By my reading of how this pattern works, each successor is called until a successor in the chain handles the call. Then the chain stops. This is stated at the top of page 224 of the Design Patterns book. The example for Java shows each item on the chain being able to perform some example. So I don't think it is an actual example of a 'pure' chain of responsibility. Pcraven 20:10, 11 February 2007 (UTC)

I agree with Pcraven. Java example contradicts this statement "Each processing object contains a set of logic that describes the types of command objects that it can handle, and how to pass off those that it cannot to the next processing object in the chain." The example passes on the responsibility to next logger even if it could handle it. Sameergn (talk) 03:42, 8 March 2009 (UTC)

I agree and disagree with Pcraven. The Filter chain in the Servlet API is an implementation of this pattern. In the Filter chain the processing is continued just like the example, but in contradiction to the definition provided by the GoF. IMHO I think the people of SUN have thought thoroughly about the choice for this pattern. It turns out that the pattern can be used in a different setting then thought of by the GoF. Because I knew the FilterChain before reading the description by the GoF I was actually surprised to find out that the chain would stop. But thinking of selection of jdbc drivers made me understand. I think this example is correct although quite rudimentary and another example could be added to show the original way how the CoR can do its job. Loek Bergman (talk) 09:17, 16 June 2009 (UTC)

I disagree: Continuing the execution is a smart thing in some cases of course, but then that is clearly not this pattern but a custom one. I would rather categorize it as some kind of observer hacked together with a linked list because each member gets the message independently of the ones before. MoZo1 (talk) —Preceding undated comment added 14:46, 4 October 2009 (UTC).

There seems to be a problem with the C# example as well. My November 2003 copy of Design Patterns state about the Chain of Responsibility pattern that ″The first object in the chain receives the request and either handles it or forwards it to the next candidate on the chain″ (p. 224, my copy). Under the Participants heading, about the ConcreteHandler, the book reiterates that ″if the ConcreteHandler can handle the request, it does so; otherwise it forwards the request to its successor.″

It's quite clear that the pattern describes an exclusive either/or relationship. Either a handler handles a request, or it passes the request on. In the C# example, and handler can both handle a request, and pass it on. This is misleading (and I have had actual discussions with people based on this, because they misunderstand the pattern because of that particular example).

Logging doesn't provide a good example of this pattern. A better example scenario could be a read-through cache, although that requires an extension to the pattern where methods can return data, instead of only mutating state. Another option for an example is the GoF's own help topic scenario. Ploeh (talk) 08:53, 11 October 2018 (UTC)

Multiple language examples

Please stop removing examples without any discussion. There's some useful info there. Please discuss why we shouldn't have all these examples, instead of wholesale removing them. Thank you. peterl 11:05, 5 March 2007 (UTC)

Here's why I would like to remove the example that pertains to logging: Every time you add a caveat to an example (e.g., "this is not the way you'd REALLY perform logging"), you add to the cognitive load for the reader. Here, there's not only one caveat, but two. It's not the clearest example in the first place, and it makes the page bulkier, so I would vote for getting rid of it. -AlanUS (talk) 01:16, 17 January 2012 (UTC)

Class Diagram

I was really expecting a more theoric example with diagrams and such... I think it is really useful to anyone who want to understand the pattern and apply into their project...189.59.206.104 (talk) 17:21, 16 July 2008 (UTC)

Python Example

I think the Python example does not show the Chain-of-responsibility pattern. In the example every handler will be executed. This does not represent the intended chain behavior. —Preceding unsigned comment added by 194.8.210.119 (talk) 10:19, 23 June 2010 (UTC)

Processing Objects

The role of **processing objects** should be better illustrated by the examples. And I agree that a more general introduction, with some explanations of the solved problem would be highly wellcomed. — Preceding unsigned comment added by 194.150.244.94 (talk) 10:16, 1 December 2011 (UTC)

Command object needed?

This article currently states:

"In object-oriented design, the chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects."

Is the use of command objects required for a pattern to be qualified as the chain-of-responsibility pattern? The currently provided examples don't seem to be using full-fledged command patterns (i.e., they don't consist of invoker, commands, receiver, and client).

--Abdull (talk) 12:43, 9 July 2013 (UTC)

IVSR

A couple of weeks ago, an IP editor added or altered the examples on a number of pattern-related pages to imply that they were from IVSR. This page makes it particularly obvious, since that was the only reason to make this edit. I can't find any pattern-related book or other programming examples that in any way relates to those initials. In some cases, it seems clear that these patterns have come from other sources on the web. Does anybody know what IVSR is, or should it be removed as some form of self-promotion? – RobinHood70 ^talk 16:37, 10 September 2014 (UTC)

ifelseifelseifelseendif

Added a 'dubious' tag to a statement about how this pattern is an object oriented version of if else if else... for that to be true, the pattern would have to enforce the condition that if one processing object is executed (in other words, is true) then the other processing objects will not be executed, as you would experience in an if else if else type block. As it is, any or all of the processing objects could be executed, and that is not possible in an if else if else block. Haxwell (talk) 21:08, 23 August 2020 (UTC)

I agree, I don't think just the fact that a processing object can be configured to trigger upon certain conditions make them if-else statements. I think it should be deleted since it could come from a misunderstanding of the pattern, but "with the benefit..." can be kept because it shows how the chain can be dynamically reconfigured. 0xDeadbeef (talk) 14:13, 8 November 2020 (UTC)

Examples too many and too long?

(Insert Simpsons' "Old Man Shakes Fist At Cloud" image here.)

The example section seem far longer than necessary for illustrative purposes. The examples each need to either illustrate something different about the pattern, or something different about how the pattern is used in the example language. I'd rather see minimal terse pseudo-code demonstrating the point of the text of the article than hundreds of lines of technically correct and well commented code that takes up several pages at the old-person zoom level I use. I couldn't pick any particular example to remove or trim but at the very least the introduction to each example should explain why I'm being presented with that particular example. Something like "this shows how the pattern protects the programmer from being hamstrung by the strict typing of this language." Or "this shows an alternative way of implementing the pattern where ... instead of ... which is useful because ..." Crag (talk) 18:27, 25 January 2023 (UTC)