There have been several discussions on this list about using
"specifications" to implement the get/find behavior of Repository
classes. I've read Evans/Fowler paper on the Specification pattern a
few times now and I love the idea but I guess I lack imagination when
it comes to implementing it as it's described in the paper in a way
that stays true to the pattern and works for Repositories, which
usually hide a large database.

At its simplest, a Specification is a class that can evaluate any
candidate object and tell us if it satisfies a particular contract:

interface Specification {
public boolean isSatisfiedBy(Object candidate);
}

Trying to solve the Repository.find() problem with a Specification is
tricky because Repositories usually hide large collections of
candidate objects that live in a remote database system. It's simply
not practical to load candidate instances so that your Specification
can pass judgment on each one. You're better off formulating a query
and letting your database hand you the candidates that satisfy your
specification.

This invariably leads to an implementation much different than the
Specification described in the paper by Evans and Fowler and lacking
some of the snazzy features they describe like Composite
Specifications.

I'm curious to know how closely your implementations of Specification
resemble the Specification pattern as described in the Evans/Fowler
paper. My attempts at using the Specification pattern to build find()
methods in Repositories always end up feeling more like Query or
Command object implementations that are distinctly different (and less
useful) than the Specification pattern in the paper. I'm wondering if
I'm missing something.

Here's the Evans/Fowler paper: http://www.martinfowler.com/apsupp/spec.pdf

Any thoughts on this are appreciated.

Hernan,
San Francisco