Comments on: Obsev :: Implementing Domain Friendly, Predicates-like Specifications with C# 3.0 Expression trees

By: sadek

sadek — Mon, 26 Mar 2007 19:13:08 +0000

Personally, i dont guess you can reuse specifications themselvs. You might reuse there classes, but not themseleves… I guess that each specification belongs to one scenario, and cant be reused even if they look so (think of design by contrats and invariants–Spec# Research ).

For the expressiveness, doesnt it look expressive what I ve just wrote up? of course if we write all our specification in a one line, that will look rather unreadable, but dividing it into a predicate style makes it as expressive as a custom designed specifications. By the end, this technique doesnt guarantee readability suddenly and magically, so best practices are needed.

And if you need to extend it, it is as easy as defining extension methods, exactly as i did for the “And”.

I revisited the example, because i wasnt comfortable with the word “Invoke” repeated in the result of the ToString() , with the new implementation i used the internal Visitor class, to revisit parameters so that i will not get this ugly Invoke I can pass you the revised sample if interested.

By: Tim McCarthy

Tim McCarthy — Mon, 26 Mar 2007 05:03:30 +0000

So, are you saying that instead of using specifications, we should just use LINQ expressions as the specification, and have the LINQ expression be of the type Expression?

I was thinking about that too, and I am just curious if LINQ expressions can actually do away with having to write our own specification classes. It will eliminate code, but may also get rid of some of the expressiveness of the code. Specification classes can be a nice place to hold domain logic…just wondering out loud where we will hold these expressions so that they too can be reused.

– Tim

By: sadek

sadek — Wed, 28 Feb 2007 10:32:43 +0000

First of all thank you for your comment Wes
Your question of why to use expression trees makes sence in my example, but unfortunaitly i had to do it this way because i couldnt find a way to do it without invoking the precedent expressions.
what i would like to do (and i couldnt acheive), is to build an expression tree specification, that i can analyse in a factory for building an object (Building to order) , where true/false result result doesnt help much in that case .
Yes in my example i can still analyse the to string i get from ToString (analysing a string is far more limited than analysing a real full ExpresionTree)
So my aim was to build a Generic Specification that i can use for the all three specifications needs. If you have any suggestions, i ll be interested.

By the way, there are some types of Expressions that i didnt get , such as a Funclet, or a StrongCard (i am not sure about the name because i dont have Orcas at work :p)

And finally i would like to suggest an interface for all expressions that take two parameters, this way i can write

if(exp1 is TwoParameteredExpression){
//here i can get the parameters and the operation and analyse their types
}
well not absolutely a two parameters expression interface, but my suggestion is to group expressions in a way that ease analysing with less casting…

By: Wes Dyer

Wes Dyer — Mon, 26 Feb 2007 19:00:40 +0000

Good post. I especially love the fact that you demonstrate how to abstract the predicate (to a delegate) and then how to compose this abstraction using things like And. The only question I have is why use expression trees? Lambdas can be converted to either a delegate (invocable) or an expression tree (examinable). In the code, you only ever combine, compile, and invoke the lambdas so they could easily just be delegates; however, if you want to examine and then act on the structure of the lambda then it would be very compelling to store them as expression trees.

public static Predicate And(this Predicate p1, Predicate p2)
{
return x => p1(x) && p2(x);
}

Of course this definition would not be sufficient if I needed to examine the structure. So if I translated all ands *inside* of a lambda to calls to And then that would make a lot of sense. Because I am using expression trees to examine the contents of a lambda and then act on that (perhaps redefining it).