> If they are different then it makes sense, in my eyes (and I'm myopic, so give that consideration), to decouple the > handlers by not allowing them to call their successors. The client (the pipeline processor in the SSCE example) still > sets it up, but the client has a little additional responsibility of passing the message to the successor itself.
Agreed. In fact, I wasn't trying to dismiss CoR at all. I would certainly consider CoR for the problem expressed (the hooking up of multiple Strategy objects to a single task) if there was no dependency between the strategies themselves. CoR is a great pattern for passing a request to multiple "handlers" to examine, but the problem is that in its simple form you have very little control over the order of execution or whether the request will continue down the chain at all. When you start trying to enforce those things it complicates the pattern and likely your logic and implementation. That's generally the point where I would stop and ask if there is a better way to solve the problem - in this example, if I had to have control over which objects are involved and need to dictate what order the operations execute then I would probably use a Fa�ade to simplify the execution path and then have a factory create each distinct fa�ade based on the request. > Enjoying the conversation. Thanks! Me too, thanks. I think all the discussion just proves that you have to consider all the elements of your problem before choosing the way to build it and that there are probably many appropriate ways you can go about it.. Best Regards, Mark Smith =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
