Pattern: DiscriminatorPattern

I think I HaveThisPattern, I've not so much mined as had a eureka moment when asked to suggest an OO solution to a batch process where the selection criteria is subject to more changes than the content of the batch itself or the handling (in this context generating a mailing list from a data warehouse). I realized I'd used the same solution in a different context for a dynamic filter for logging business event from a transaction stream. So I've tried to generalize the shape of it and it now seems like a perfectly obvious solution to any case of handling or processing a subset of items from a collection, a batch, or a stream, where the selection criteria changes dynamically. I've not seen it in any pattern catalogues.

It is similar to some other patterns.
The overall structure is similar to DispatcherPattern, but it differs in that it is the discriminator that changes does not do the ultimate processing.
It provides similar structure to ProxyPattern but differs in behaviour.
It provides similar behaviour to an InterceptionFilter, but differs in that it separates the selection from the handling. 

'''Pattern Name''':  Discriminator. ''I'm not really happy with this name it is perhaps a little loaded.''
	
'''Classification''': Behaviour
	
'''Intent''': 	Process a subset of objects from a batch or collection, separate selection from how the subset is processed as per the principal of a single responsibility.

'''Also Known As''':  

* Selector. (The semantics of this Selector doesn't seem to capture the essence of the pattern) 
* Filter - To similar to an Interception Filter. 
	
'''Motivation''': To serve the needs of separating responsibilities, 

The discriminator and handler are defined in separate classes. Separate the selection of object from it's processing.
	
'''Applicability''':  When the collection is static, and the selection criteria are dynamic.  Seems particularly useful when the selection criteria is more volatile than the collection or the handling.

'''Structure'''

'''Participants''':
		
* Client: This is the driving process which encapsulates the Collection, and uses an Iterator against the Element, it uses a factory to load the Discriminator and Handler
* Discriminator: This is custom selection criteria.
* Handler: This is the handler for the selected elements.
	
'''Collaborations'''

'''Consequences'''

'''Implementation'''

'''Sample Code'''

'''Known Uses'''
 
* Batch processing.
* Filtering a subset.
* Polling.
	
'''Related Patterns''':
		
* The Client may utilize a Factory to construct the Discriminator,
* The Discriminator will use a Facade.
* The Client may utilize a Factory to construct the Handler,
* The Handler will use a Facade
* The Discriminator may utilize a Chain of Responsibility, to allow multiple operations on the subset.
* The Iterator may utilize a Factory to construct the Discriminator,

''How is this different from the "filter" HigherOrderFunction; standard in any decent FunctionalProgrammingLanguage?''

Maybe it is a pattern for languages without meta abilities. See AreDesignPatternsMissingLanguageFeatures.
----
CategoryBehavioralPatterns