If you don't know what a predicate is... a predicate is a function that takes (meaning - returns) logical ("boolean", in programmese) values. Since you have operations on logical ("boolean") values, you can apply them to predicates to produce other predicates.
So far so good, right? Having a predicate, you can define "filter" on a collection (set, list, array) - similar to SELECT WHERE (note that there's no SELECT WHEN, because the logic of SQL is boolean, and temporal logic is not).
This seems to be enough to deal with conditions. Hibernate does it when you use HQL and build compound conditions.
But no! Not everybody who does not know what a predicate is goes ahead and reads about it. Some people just invent them. Look at
this. "In computer programming, the specification pattern is a particular software design pattern, whereby business logic can be recombined by chaining the business logic together using boolean logic." The article mostly consists of two pieces of crappy C# code (crappy and crappier), and has references like "The Specification Pattern: A Four Part Introduction using VB.Net".
As someone (last time it was Erik Meijer, last night at BAHASKELL meeting in EY in SF) said, nothing that has "science" in its name is actually a science. This perfectly applies to CS.