Affects Version/s: None
Fix Version/s: None
Part of this request includes:
This one is just a general feedback on visitor names; I know this is no fault of your own....
There is a much loved/hated class called PostPreProcessFilterSplittingVisitor ... your new abstract base class PrePostFilterVisitor is close enough in name that I am always going to be confused.
I am going to guess that you use this base class for more than just the search (and replace) examples provided? If not I would love to call this AbstractSearchFilterVisitor; and then the other classes would cleanly follow from it...
Other than that I gotta say that this preVisit( object, data ) and postVisit( object, data ) is exactly what the visitor pattern is trying to avoid (ie the implementations are performing instance of checks in here to try and recover the type information you just threw out.
I am going to think a bit more about what you have here and see if I can help; it looks like you were trying to duck out of implementing filter traversal while still being able to subclass quickly and "process" the data structure.
This is supposed to be possible with DefaultFilterVisitor; it may be a design or documentation flaw if you did not find this usable.