The only thing I don't like about it is performance. The same old thread drives the process of letting each handler in the chain examine the object. That's why a naive implementation of CoR is only a decent solution when you're sure that the number of handlers is guaranteed to be relatively small.
In a multi-threaded situation, though, where each handler can examine the object on its own time (and perhaps simultaneously), letting the handler decide whether to handle the request works just fine. This is part of the beauty of JavaSpaces.
You can also implement a multithreaded lookup processor, where each lookup thread examines a group of potential handlers until one is found, to good effect in certain situations.
In actual practice, I've found that it's better to let an external controller check each item in the "chain" for its ability to handle the request, and if not, check the next. This lets you dispense with the chain/list itself, instead treating the items as an array. This is good because you always have to be able to interrupt the sequence (like in case of interrupt or shutdown requests being received by the application). To build the interrupting logic into a chain class (like FilterChain) makes it less of a clean implementation, and there's no problem with letting the controller handle this.
Jeff
jvarszegi@hotmail.com
|
Previous
Index
Next
Flat
CoR is admittedly nice in some ways
Edit
Reply
Quote
