Manfred Wolff wrote:
I would agree with that sentiment in general, but there are likely to be use cases for dynamically configuring a chain (either one-off for a specific need based on (say) a bunch of query parameters or the input data in a web service call, or synthesized at app startup based on overall configuration parameters, and then stored in a catalog for reuse).
Vic.
Hmmm. I think the "chain of responsibility" pattern is not made to configure the chains on the fly ;-). If you have a decision configure all chains that are envolved and let the commands themself decide if they can fulfill the business logic or not.
However, trying to figure out the next command to execute in a *currently executing* chain seems to go against the purpose of the Chain of Responsibility pattern. The idea is that each command should be small and self contained, so that it is reusable (and unit testable) without knowing anything about the other commands that might be part of the chain. Commands that need to pass state information along should do so by storing it in the context under some agreed upon attribute name.
After all, in the execute method of a specific command, you can say something like:
Command nextCommand = new FooCommand();
if (nextCommand.execute(context))
return true;if you really want to -- but why bother to make FooCommand into a command in the first place? If it's just arbitrary business logic, you can also call it directly and be done with it.
Vic, it would be interesting to explore in more detail the use case you are thinking about, in order to determine whether Chain of Responsibility is the right pattern or not. What did you have in mind?
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
