Builder Design Pattern Update

Recently, a reader made me aware of some old code. Today, we revise our Builder Design Pattern with an updated library.

Three years ago, I wrote how to create a filter using a Builder design pattern and passing that expression into a query to return results.

This post was production code and is currently providing search results as we speak. ;-)

In the post, I also mentioned using the PredicateBuilder from the C# in a Nutshell book.

While this PredicateBuilder is now included in the LinqKit library, one reader (Thanks, Kevin!) made me aware of the syntax was deprecated and provided me with an update.

LinqKit Example

Once you include this library, the updated syntax should look similar as we replace one line.

In the Build method, I had:

public Expression<Func<Product, bool>> Build()
{
    // old and busted
    var predicate = new Expression<Func<Product, bool>>();

Now, our updated version is a little more modern (changes in bold).

public Expression<Func<Product, bool>> Build()
{
    // new hotness
    var predicate = PredicateBuilder.New<Product>(true);

Once you make this change, your AndAlso methods should light up as well. Replace the AndAlso's with .And. The syntax should work the same. 

Everything should function as normal.

Bonus: Ed Charbeneau's PredicateExtensions

After watching Ed at Codemash 2018 with his session on Going All in With Functional C#, he demonstrated how powerful functional programming can be with C# by playing cards (you'll just have to go next time).

He also released a PredicateExtensions library as well.

His syntax is just as easy. Include his library and the syntax becomes:

public Expression<Func<Product, bool>> Build()
{
    // Search Term
    var predicate = PredicateExtensions.PredicateExtensions.Begin<Product>();

For more on how to extend expressions, I urge you to check out his post on Giving Clarity to LINQ Queries by Extending Expressions.

Conclusion

The best part about design patterns is that they provide solid solutions to common code problems.

As I mentioned above, the builder design pattern post was written three years ago. I've used this design pattern numerous times since then. 

This is why it's best to learn design patterns. Once you understand and implement a design pattern, it will immediately give you dividends throughout your career.

While libraries and frameworks may change over the years, design patterns are the concepts that stand the test of time no matter what language you use.

Which this post just proved.

References:

• If you are interested in more design patterns, check out the Top 10 Programming Books Every .NET Developer Should Own and examine the Refactoring to Patterns, Refactoring, and Design Patterns in C# books. They. Are. Gold!
• My collection of Real-World Refactoring techniques.
• Review of Refactoring Into Patterns (A Signature Series book).

Have you implemented this design pattern in your code? Did you have to modify it? What changes did you make? Post your comments below and let's discuss.