Comparison
Query objectvsSpecification pattern
Query object
the filter was built up as an object and handed to the repository, instead of being ten optional parameters.
Representing a query as an object that can be composed, passed around and translated into SQL at the edge. It keeps a repository from growing forty finder methods, one per combination of filters the UI has ever needed. The specification pattern is a domain-flavoured version of the same idea, with the extra requirement that the criteria are also checkable against an object in memory.
Full entry →Specification pattern
the rule for what counts as a lapsed customer is one object, used both to filter the query and to check one in memory.
Encapsulating a business rule as an object that can answer whether a candidate satisfies it, and that can be combined with and, or and not. Its strongest form is one rule usable in two places — evaluated against an object in memory and translated into a query — which is what keeps the definition of 'lapsed' from existing twice. It is worth the machinery only when the rules are combined or reused; a single predicate is better as a method.
Full entry →