The umbrella term for everything you've learned this module — functions that take other functions as input, return them as output, or both.

Look back across this entire module: Retrier.RunWithRetry took an Action as a parameter. OrderValidator.AddRule took a Func<Order, bool>. List<T>.Find took a Predicate<T>. CreateCounter returned a Func<int>. Every one of these is doing the exact same kind of thing: treating a function as a piece of data — accepting it, passing it along, or handing one back.

That general pattern has a name: a higher-order function. It's not a new C# feature — you've been writing and using them since lesson 098. This lesson names the pattern explicitly and shows you how to combine everything you know to build genuinely flexible, reusable code.

What Is It?

The Simple Explanation

A higher-order function is any function that does at least one of these two things: takes another function as a parameter, or returns a function as its result. A function that only ever accepts and returns "plain data" — numbers, strings, objects — is a first-order function; the moment a function itself becomes an input or an output, you've stepped up a level.

The Technical Definition

This concept rests on treating functions as first-class values — values that can be stored in variables, passed as arguments, and returned from other functions, exactly like an int or a string can. C# achieves this entirely through the delegate machinery you already know: Action, Func, Predicate, lambdas, and local functions converted to delegates are all just ways of turning "a function" into "a value" you can move around your program.

Why Does It Exist?

The Problem — Hardcoded "How" Forces Duplication

Imagine writing a separate retry method for every operation your app performs — one for saving to a database, one for calling an API, one for writing a file — each with near-identical retry-loop code, differing only in the one line that actually does the work. Every new operation means copy-pasting and re-testing the same orchestration logic.

The Solution — Separate "What Varies" From "What Stays Fixed"

A higher-order function lets you write the orchestration logic (the "how" — retry looping, validation iteration, sorting, filtering) exactly once, and accept the varying part (the "what" — the specific operation, rule, or comparison) as a parameter. This is inversion of control applied at the function level: instead of a method calling out to hardcoded logic, the caller hands in the logic the method should run.

Big Picture

How It Works

Simple Example

using System;

class Program
{
    // Takes a function in — a higher-order function
    static int ApplyTwice(Func<int, int> f, int x) => f(f(x));

    // Returns a function out — also a higher-order function
    static Func<int, int> CreateMultiplier(int factor) => x => x * factor;

    static void Main()
    {
        Console.WriteLine(ApplyTwice(x => x + 3, 10)); // (10+3)+3 = 16

        Func<int, int> triple = CreateMultiplier(3);
        Console.WriteLine(triple(7));                  // 21
        Console.WriteLine(ApplyTwice(triple, 2));       // triple(triple(2)) = triple(6) = 18
    }
}

Code → Meaning → Result: ApplyTwice doesn't know or care what f actually does — it just knows it's a Func<int, int> and calls it twice. CreateMultiplier doesn't compute a value at all; it builds and hands back a new function, closing over factor (a direct application of closures from lesson 102). The last line even feeds one higher-order function's output into another — triple, itself created by a higher-order function, is passed into ApplyTwice, another higher-order function.

Real-World Example

A text-processing pipeline: a list of independent Func<string, string> transformation steps, applied in sequence, with new steps addable without touching the pipeline logic itself.

using System;
using System.Collections.Generic;

public class TextPipeline
{
    private readonly List<Func<string, string>> _steps = new();

    public TextPipeline AddStep(Func<string, string> step)
    {
        _steps.Add(step);
        return this; // enables fluent chaining
    }

    public string Run(string input)
    {
        string current = input;
        foreach (var step in _steps)
            current = step(current); // each step's output feeds the next step's input
        return current;
    }
}

class Program
{
    static void Main()
    {
        var pipeline = new TextPipeline()
            .AddStep(s => s.Trim())
            .AddStep(s => s.ToLowerInvariant())
            .AddStep(s => s.Replace("  ", " "));

        string result = pipeline.Run("   Hello    WORLD   ");
        Console.WriteLine($"'{result}'"); // 'hello world'
    }
}

TextPipeline knows absolutely nothing about trimming, casing, or whitespace — it only knows how to run a list of Func<string, string> values in order. Adding a step that strips punctuation or normalizes line endings later requires zero changes to TextPipeline itself — exactly the same "closed for modification, open for extension" benefit you saw with OrderValidator back in lesson 099, now generalized. This same shape — one orchestrator, many interchangeable functions — is precisely the mental model LINQ is built on, which is the very next module.

Analogy

Under the Hood

There's no new runtime mechanism in this lesson — "higher-order function" is a name for a pattern, not a distinct C# feature. Every example above compiles down to exactly what you already know: Func/Action delegate instances, wrapping either a compiler-generated lambda method or a named method, invoked through the same Invoke mechanism from lesson 096. When a function returns another function that closes over local state (like CreateMultiplier capturing factor), the compiler-generated display class from lesson 102 is what keeps that state alive for as long as the returned delegate is reachable. Recognizing "this is a higher-order function" is entirely a design-level skill — it tells you nothing new about how the code executes, but a great deal about how to structure code you haven't written yet.

Common Confusion

1. "Higher-order" doesn't mean "more important" or "more advanced-sounding"

The term describes a precise, technical property — operating on functions — not a vague sense of sophistication. A single-line utility like ApplyTwice is just as much a higher-order function as an elaborate pipeline system; complexity isn't the criterion.

2. Higher-order functions vs functional programming as a whole

Higher-order functions are one building block of functional programming, not the entire paradigm. C# remains a fundamentally object-oriented, imperative language that happens to support this functional-style feature well — you're not "switching paradigms" by using Func parameters, just using one more tool from a broader toolbox that C# gives you access to.

Common Mistakes

Mistake 1 — Over-abstracting logic that's never actually going to vary

Turning every method parameter into a Func "just in case," even when a piece of logic genuinely has one fixed implementation and always will. This adds a layer of indirection that makes the code harder to read for no real flexibility gained.

Reach for a higher-order function when you can point to at least two genuinely different behaviors the same orchestration logic needs to support — not preemptively for logic that has never needed to change.

Mistake 2 — Forgetting that a returned closure keeps its captured state alive

Calling a factory function like CreateMultiplier repeatedly inside a hot loop, unaware that each call allocates a new closure holding its own captured factor — this is easy to miss once the pattern from lesson 102 is out of sight.

Create the function once, outside the loop, and reuse the resulting delegate value across iterations whenever the captured state doesn't need to change per iteration.

When Should I Use It?

• Building reusable utilities where the orchestration ("run this many times," "run this until it succeeds," "run this on every item") stays fixed but the operation itself varies — retry helpers, pipelines, validators, sorting/filtering with custom logic.
• Implementing patterns that would otherwise need a strategy-style class hierarchy — a Func parameter is often a lighter-weight stand-in for a single-method interface.
• Skip it when there's only ever going to be one implementation — a plain method call is clearer and has one less layer of indirection to trace through.

Mental Model

Key Takeaway

Check Your Understanding

Let's confirm you can recognize the pattern across different code shapes — and know when reaching for it actually pays off.

You now see the pattern that ties Action, Func, Predicate, lambdas, closures, and local functions together. Next up: a different application of functions-as-values — the event keyword, and why plain multicast delegates aren't quite enough for safe publish/subscribe.

dotnetmadeeasy.com — Learn C# and .NET, the right way.