You are corrrect. I was trying to demonstrate what I thought were two useful approaches to a CoR with the primary difference being the decoupling between handlers. I believe this better accommodates the last statement in your last response:
"Chain of responsibility is another option for creating them, although if the strategy objects are completely different, can be added or removed dynamically, or the relationship between the algorithm and the key isn't fixed then the factory is generally a better option as it removes the coupling between all the strategies themselves." 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. Perhaps a better example of what I am trying to express is "Pipes and Filters" in POSA and Enterprise Integration Patterns. It might be my mistake of calling this another manifestation of CoR, but I prefer to consider such patterns specializations rather than entirely different. Enjoying the conversation. Thanks! Chad On Tue, 29 Mar 2005 09:07:15 -0600, Mark Smith <[EMAIL PROTECTED]> wrote: > > Perhaps a good analogy is Site Server Commerce 3.0 and its use of the > "pipeline" (I don't recall if this was in prior versions or not... > > it's been a while). The "pipeline" had a non-hierarchical arrangement of > components that implemented the > > IPipelineComponent interface (I think that was the name). The message (a > name-value object, if I remember correctly) > > would be passed into the pipeline and each component in the chain had the > opportunity to annotate the message in their > > own way. The components were decoupled from one another and they were not > hierarchical; being hierarchical implies a > > coupling as the child has to be aware of the parent and vice versa. The > CoR decouples any knowledge of parent from > > child or predecessor to successor by coordinating the passing of messages > between them. > > Right? > > I've not used Site Server, but what you are describing doesn't sound like a > traditional CoR implementation to me.. In the CoR pattern, you create a > chain of objects to examine a request and each object decides whether to > pass it on to the next object or process it. In effect, each node "knows" > about the next node (at least as an interface) and decides whether the > request will continue down the chain. In looking at the interface > definition for IPipelineComponent, it has processing support but there is no > linkage to connect a chain together or to continue the processing down the > chain. Maybe I misread it, but it looks like something above the > IPipelineComponent is acting as a list owner and knows about each registered > component which is what the CoR avoids. > > I completely agree that CoR is very useful. I think the CoR pattern has > great merit when you want to give more than one object a chance to process a > request. If you are mapping to only a single processing object then it > might be overkill. > > Best Regards, > Mark Smith > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at http://discuss.develop.com > =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
