Talk:Chain-of-responsibility pattern

message: 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)
thread_title:  Problem statement needed 

message: 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)
thread_title:  Is the example correct? 

message: 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)
replies: text: 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)
thread_title: Multiple language examples

message: 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)
thread_title:  Class Diagram 

message: 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)
thread_title:  Python Example 

message: 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)
thread_title:  Processing Objects 

message: 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)
thread_title:  Command object needed? 

message: 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 . 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)
thread_title:  IVSR 

message: 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)
replies: text: 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)
thread_title:  ifelseifelseifelseendif 

message: (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)
thread_title:  Examples too many and too long?