Works better in what way? I can see the value when used in a hierarchical situation, and I've implemented it in that way when creating simple parsers for custom XML vocabularies.
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 have personally used CoR more often in the latter capacity, but both have their merits. Thoughts? Kind regards, Chad On Tue, 29 Mar 2005 09:31:38 -0500, Marco Dorantes Martinez <[EMAIL PROTECTED]> wrote: > Chain of Responsibility works better when handling events in a > hierarchical object (not class) structure, where any given child node > object decides if handles the event or delegate to the parent node > object, think of it like cascading or event bubbling, the original > context of the pattern is handling help requests pressing F1 on a user > interface, the UI widgets are arranged in a hierarchical object > structure with some of them having help to display and other not. > > > -----Original Message----- > From: Unmoderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Chad Osgood > Sent: Tuesday, March 29, 2005 8:15 AM > To: [email protected] > Subject: Re: [ADVANCED-DOTNET] Most appropriate design pattern to use > for ... > > "One thing I'll add > is that using a "Strategy factory method" will not easily fit the > purposes > here either because using multiple Strategies is actually involved in > processing a document." > > That's pertinent information :-) Again, the factory can still be used > to simply *identify and create* the appropriate Strategy; however, you > will need more to coordinate the processing of multiple Strategies. > You wouldn't want the Strategy itself to hold this information, > because you introduce an unnecessary degree of coupling between > Strategies. > > After hearing your latest requirement I now agree with Saad; chain of > responsibility will provide the extensible coordination between > Strategies without introducing a coupling between them. Strategy will > of course still be used, and you can still choose to use a factory to > actually identify and create the appropriate Strategies that > participate in the chain if you so desire; your choice. > > Google around for Chain of Responsibility and you'll find yourself > inundated with sample implementations. > > Kind regards, > Chad > > On Tue, 29 Mar 2005 07:46:47 -0500, Bill Bassler > <[EMAIL PROTECTED]> wrote: > > From my perspective, I think you're right on the mark. One thing I'll > add > > is that using a "Strategy factory method" will not easily fit the > purposes > > here either because using multiple Strategies is actually involved in > > processing a document. I suppose a single Strategy could encapsulate > > multiple sub-processes though. For example, I have two discrete > processes > > involved to complete document processing: 1. Process/transform the > received > > message. 2. Submit the transformed message to specific processor out > of > > many potential processors. > > > > From what I understand about chain of responsiblity, it does kind of > fit > > but seems maybe a bit more than I might need. It does, however, look > like > > it's suited to defining multiple processing paths in a very flexible > way. > > Is there a good reference to get a handle on an interception filter > > implementation? > > > > =================================== > > 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(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > > =================================== > 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
