---
title: "Discussion on \"A Practical Guide to Higher Order Functions in C#\" | Hashnode"
description: "Discussion on \"A Practical Guide to Higher Order Functions in C#\". If you have been programming for any length of time, you may well have come across higher order functions, but (like me) may not have fully appreciated just how powerful they can be. If you've not heard of them before, never fear, I have an explanati..."
url: "https://hashnode.com/posts/a-practical-guide-to-higher-order-functions-in-c/60e03e704f8e376422a7725e"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [A Practical Guide to Higher Order Functions in C#](https://samwalpole.com/a-practical-guide-to-higher-order-functions-in-c?utm_source=hashnode&utm_medium=feed)

If you have been programming for any length of time, you may well have come across higher order functions, but (like me) may not have fully appreciated just how powerful they can be. If you've not heard of them before, never fear, I have an explanati...

Jul 3, 2021 · 3 min read · samwalpole.com  
Updated Aug 25, 2024  
Read the article

-   [#csharp](https://hashnode.com/tag/csharp)
-   [#dotnet](https://hashnode.com/tag/dotnet)
-   [#dotnetcore](https://hashnode.com/tag/dotnetcore)
-   [#functional-programming](https://hashnode.com/tag/functional-programming)
-   [#functions](https://hashnode.com/tag/functions)

## Written by

[Sam Walpole](https://hashnode.com/@dr_sam_walpole)

@dr\_sam\_walpole · United Kingdom

  
[View profile](https://hashnode.com/@dr_sam_walpole)

👨‍💻 Fullstack .NET and JavaScript teacher and advocate 👨‍💻

## Responses 3

Markdown supported · ⌘↵ to post

[Frédéric Delaporte](https://hashnode.com/@fredericDelaporte)

[Feb 22, 2024](https://hashnode.com/posts/a-practical-guide-to-higher-order-functions-in-c/60e03e704f8e376422a7725e/comment/65d76a7234c9e027a2ee205c)

About Linq, a `Func<Product, bool> filter` is in most cases (excepted linq-to-object) a bad choice. It will not leverage the capabilities of linq-to-entities or linq-to-nhibernate and the likes to perform the filter in the database. Instead, it will cause the data to be entirely loaded in the application memory and filtered in memory. It works only with Enumerable extensions, not with Queryable extensions.

The fix is easy enough: use an `Expression<Func<Product, bool>> filter`. And of course do not use it with a foreach loop, but with Linq Queryable extensions. A note about that should be added in your blog post.

Actually, the pattern proposed by this blog post looks valid to me only if used with a Linq Queryable provider. Otherwise, how would it allow to perform the query filtering in the data store rather than in the application memory? Or am I missing something?

[Nick D](https://hashnode.com/@niico)

[Jul 12, 2021](https://hashnode.com/posts/a-practical-guide-to-higher-order-functions-in-c/60e03e704f8e376422a7725e/comment/60ec7396573c235ee639d532)

Never write "simply put", it's verbiage. Just say what you want to say.

[Saby](https://hashnode.com/@Saby)

[Jul 5, 2021](https://hashnode.com/posts/a-practical-guide-to-higher-order-functions-in-c/60e03e704f8e376422a7725e/comment/60e33ec5b1f6172d201b5338)

Nice article Sam! What i'd like to point out, in your repo pattern is that, for me at least, having different methods conveys the intention of the code better than a generic filter. For example, with GetById, you just look for references of the method or search it to see where exactly is used. With a generic filter I think it would be harder to find, especially in big code bases, where it tries to bring a Product by Id and follow the logic of the code.