Comments on: Coding: Missing abstractions and LINQ

By: Aaron Erickson

Aaron Erickson — Tue, 19 Jan 2010 14:24:52 +0000

No idea – I don't write Ruby often :/

But inheriting your base from DynamicObject I can easily imagine how this will work.

By: Mark Needham

Mark Needham — Mon, 18 Jan 2010 22:58:02 +0000

@Aaron yeh that would work quite well in this situation as you say. How would this type of thing work in Ruby?

By: Jordan Terrell

Jordan Terrell — Mon, 18 Jan 2010 15:58:59 +0000

And it did! DOH! One more time, with HTML escape sequences

someFooHolder.Foos.Meets();

By: Aaron Erickson

Aaron Erickson — Mon, 18 Jan 2010 15:57:20 +0000

Maybe there is a good opportunity for Dynamic here

Something that converts the method name into the appropriate lambda dynamically… too magical?

By: Jordan Terrell

Jordan Terrell — Mon, 18 Jan 2010 15:57:17 +0000

Looks like the commenting engine striped out some of my example. This first example should be:

someFooHolder.Foos.Meets ();

Hope this doesn't get striped out also!

By: Jordan Terrell

Jordan Terrell — Mon, 18 Jan 2010 15:55:44 +0000

I agree with Jaco. When the LINQ expression is fairly simple and used frequently, then writing an extension method makes good sense. However, when the expression is complicated or composed of multiple, perhaps reusable parts, I like the Specification pattern: http://martinfowler.com/apsupp/spec.pdf

For example:

someFooHolder.Foos.Meets();

someFooHolder.Foos.Meets(new CompletedFooSpecification());

That may seem more involved – and it is. However, the specification pattern can give you (more) Separation of Concerns and composability, if you *need* it. If not, then extension methods is an good choice.

By: Jaco Pretorius

Jaco Pretorius — Mon, 18 Jan 2010 09:52:41 +0000

Interesting post – I agree that we tend to duplicate LINQ expressions quite often. If I find I'm re-using a LINQ expression I usually write a custom filter (extension method) and then simply re-use the extension method. The cool part about this approach is that you can unit test the filter and your code also becomes much more readable.

For example, you might write

users.WithId(5) instead of users.Single(u => u.Id == 5)

By: The Morning Brew - Chris Alcock » The Morning Brew #519

The Morning Brew - Chris Alcock » The Morning Brew #519 — Mon, 18 Jan 2010 08:25:17 +0000

[...] Coding: Missing abstractions and LINQ – Mark Needham looks at encapsulating the business logic that often leaks out with the power of Linq, capturing it inside classes rather than having Linq statements dotted around your code. [...]