Thanks for the post!

However, there are reasons why you still may want an implementation on top of C# expressions. You named some of them, but I’d like to broaden the topic somewhat: Essentially the specification pattern is a special (and rather limited) incarnation of a DSL. And thus, the usual reasons for coming up with a DSL should apply here:
- raising the level of abstraction. This would gain more efficint development (say RAD style) or open “programability” to new audiences, such as power users.
- Restricting the feature set (i.e. only allowing certain operations, e.g. only those that make sense in a certain context).
- configuration/customization over implementation.
- other reasons, like being able to trace and time the execution, offloading workload to other machines, etc.

Personally I have used “specifications” (I don’t like the name either) in two situations where expression trees wouldn’t have helped anyway:
- When I needed a trimmed down “rules engine”
, i.e. some kind of configurable expressions. This is usually the case when these conditions change often or have to be changed by non-developers or on the fly (i.e. without compiling).
- When the application needed end user defined logic, espessially user defined queries, including the ability to edit, store, and execute those queries.

Regarding this post in general: The specification pattern is just one of many patterns that was conceived during the OO heydays. But other approaches, like components, meta programming, functional programming, and the general evolution of the platforms have had an effect and while OO may still be a cornerstone of todays development, it is no longer the sole characteristic. Thus today any pattern from that “early” time may seem questionable at first glance. At second glance it may simply have to be adapted to a changed environment, it may be obsoleted by some competing pattern, or it may be superseded by some broader notion. Bottom line: It’s good to ask these questions, and to question “established knowledge”, as it will at least foster a better understanding, and possibly lead to new, better ideas. Thus good work.

There is no mistaking that you could use Expressions to implement the Specification Pattern on the technical side. But that was not the question and it’s not answering the obsolete concern (btw: In my opinion this doesn’t add any value in nearly all situations in comparison to implementing the Specification Pattern by hand).

To straighten things out again: As you can see with my “focus” sections, the Specification Pattern is not obsolete for me, because it still has an important value. I’ve inserted some bottom line, thanks for the comment!

Rather than saying:

interface ISpecification {
bool IsSatisfiedBy(T candidate);
}

Simply change the interface to:

interface IExpSpecification {
Expression<Func> Predicate { get; }
}

Personally, I’m not to keen on the name specification as I pretty much have to explain that I’m talking about are filters.