While refactoring in general is good, I am not so thrilled with the concept of GenericMatchFilter because the code in LevelMatchFilter (for example) is so simple that imo it does not need refactoring. The refactored code is unlikely to be easier to understand. It's a subtle question, mostly of stylistic nature if you ask me.
If you feel strongly about this refactoring then go ahead. At 11:24 15.05.2002 -0700, you wrote: >Now that I have written some test cases for the filters in the varia >directory, I feel I have a much better understanding of them. So, now I >understand some of the comments about the filter extensions I previously >submitted for submission. They were a bit overkill in their design and did >pretty much the same thing. > >But I still think there are some useful changes that can be made in this >area. > >1) If the get/setAcceptOnMatch methods and a decide() method that uses the >set values are moved to an abstract base class, then that base class could >be used by any developer to develop their own filters that are easy to plug >into this filter chain. LevelRangeFilter and LevelMatchFilter would be >changed to descend from this base class and there would be no affect/change >to their current api. Copy and paste is your friend, not always, but in this case I believe it is. >2) Implement more filters using the abstract base class: NDCMatchFilter, >MDCMatchFilter, LoggerMatchFilter, etc. Again, they would be easily >compatible with the other filters of this type, using the same >get/setAcceptOnMatch methods in the base class. +1 Hmm, since you are going to code a bunch of these filters, refactoring into GenericMatchFilter sounds better and better although cut and paste will still result in more readable code, not easier to write, but more readable... >3) I would like to add my SetLocationInfoFilter to the set as well. It >would not use the base class since it is just a pass-thru type filter. This filter has trivial code but can only be used if properly documented. You should really explain that the SetLocationInfoFilter exists for performance reasons only and that it demands a particular filter chain structure, with event eliminating filters in front, and other filters which return ACCEPT that short circuit the LocationInfo extraction, and last but not least the SetLocationInfoFilter returning NEUTRAL and after extraction LocationInfo as a side effect. It never makes sense to have a DenyAllFilter and SetLocationInfoFilter on the same filter chain. >4) Test cases for all of the above. +100% >If folks agree, I will get started in this shortly. After this I would like >to start exploring the watchdog/reconfiguration area. Mighty cool. >-Mark -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
