Have you looked at the actual code? And have you looked at what a CoR pattern is? The actual code is not a CoR pattern. I am not interested in "hooking" anyone, by the way, and so you don't need to "bite". I guess saying you'll "bite" is like saying I am "fishing" for bullshit. That is not true. Anyway, the actual design goes as follows. Please notice that none of the iterations in Struts CoR are present, for good reason.
Chain of Responsibility Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. There is a potentially variable number of "handler" objects and a stream of requests that must be handled. Need to efficiently process the requests without hard-wiring handler relationships and precedence, or request-to-handler mappings. The pattern chains the receiving objects together, and then passes any request messages from object to object until it reaches an object capable of handling the message. The number and type of handler objects isn't known a priori, they can be configured dynamically. The chaining mechanism uses recursive composition to allow an unlimited number of handlers to be linked. Chain of Responsibility simplifies object interconnections. Instead of senders and receivers maintaining references to all candidate receivers, each sender keeps a single reference to the head of the chain, and each receiver keeps a single reference to its immediate successor in the chain. Make sure there exists a "safety net" to "catch" any requests which go unhandled. Do not use Chain of Responsibility when each request is only handled by one handler, or, when the client object knows which service object should handle the request. [ http://www.cs.huji.ac.il/labs/parallel/Docs/C++/DesignPatterns/chain.html.] The Chain of Responsibility pattern avoids coupling the sender of a request to the receiver by giving more than one object a chance to handle the request. Mechanical coin sorting banks use the Chain of Responsibility. Rather than having a separate slot for each coin denomination coupled with a receptacle for the denomination, a single slot is used. When the coin is dropped, the coin is routed to the appropriate receptacle by the mechanical mechanisms within the bank. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] Chain of Responsibility, Command, Mediator, and Observer, address how you can decouple senders and receivers, but with different trade-offs. Chain of Responsibility passes a sender request along a chain of potential receivers. Chain of Responsibility can use Command to represent requests as objects. [GOF, p349] Chain of Responsibility is often applied in conjunction with Composite. There, a component's parent can act as its successor. [GOF, p232] --------------------------------------------------------------------------------------------- On 2/18/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Dakota Jack wrote: > > The flexibility is clear. But, from what I can see the pattern is not > CoR. > > Ok, I'll bite... can you explain that? > > Frank > > > On 2/16/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > >> Craig McClanahan wrote: > >>> This pattern, of course, can be used today in a Struts 1.x action ... > or > >> in > >>> the "action" equivalent of any other framework too (JSF, WebWork, > >>> whatever). And, it's not even web specific ... you can design your > >> whole > >>> business logic layer out of chains. > >> Having done this recently in a behavioral analysis application that was > >> not web-based, I know exactly what your saying. I can't tell you how > >> thrilled the business was in a meeting a few weeks ago when they said > >> "well, what happens when we want to add a rule between C and D in this > >> processing flow" and I was able to do it in about 1 minute right before > >> their eyes. They flipped! CoR makes that flexibility very easy to do. > >> > >>> Craig > >> Frank > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > "You can lead a horse to water but you cannot make it float on its > back." > > ~Dakota Jack~ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
