C# Pass Method as Parameter: Delegates and More

When working in C#, situations arise where you need to delay a method call until another part of the code decides to invoke it. The phrase c# pass method as parameter points to this capability: passing a method reference into another method, allowing the receiving method to call it as needed. This is not a feature reserved for advanced frameworks; it appears in everyday code, such as LINQ's Where and Select methods, and in event handlers you attach with +=. Understanding how to pass methods effectively is essential for writing flexible and reusable code.

At the core of this ability is the delegate type. A delegate is a type that defines a method signature; any method with a matching signature can be assigned to it. For example:

public delegate int Operation(int x, int y);

public static int Add(int a, int b) => a + b;

public static int ApplyOperation(int x, int y, Operation op)
{
    return op(x, y);
}

In this example, Operation is a delegate type. The ApplyOperation method accepts an Operation parameter, so you can pass Add directly as a method group:

int result = ApplyOperation(5, 3, Add); // result is 8

Simplifying with Func and Action

Writing custom delegate types for every signature is tedious. The .NET framework provides generic delegates that cover most common scenarios. Func<T, TResult> represents a method that returns a value, while Action<T> represents a method that returns void. The last type parameter in Func is always the return type.

Consider a utility method that wraps an operation with logging:

public static T LogAndExecute<T>(Func<T> operation)
{
    Console.WriteLine($"Starting at {DateTime.Now}");
    T result = operation();
    Console.WriteLine($"Finished at {DateTime.Now}");
    return result;
}

This method accepts any method that returns a value, regardless of its internal complexity. You can pass a lambda or a method group:

var data = LogAndExecute(() => GetDataFromDatabase());

// Or using a named method
var data = LogAndExecute(GetDataFromDatabase);

When the method takes parameters but returns nothing, use Action:

public static void ForEach(Action<string> action, IEnumerable<string> items)
{
    foreach (var item in items)
    {
        action(item);
    }
}

This pattern is common in callback scenarios, such as progress reporting or notification.

Using Lambdas for Inline Logic

Often the method you want to pass is short and does not deserve its own named method. In those cases, a lambda expression provides a concise way to define the logic inline:

var numbers = new List<int> { 1, 2, 3, 4 };
var evens = numbers.Where(n => n % 2 == 0).ToList();

Lambdas are not limited to LINQ. You can use them anywhere a delegate is expected:

int result = ApplyOperation(5, 3, (a, b) => a * b);

The lambda's parameter types and return type are inferred from the delegate type, which keeps the code compact without sacrificing type safety.

Method Groups and Overload Resolution

When you pass a method by name, such as ApplyOperation(5, 3, Add), the compiler converts the method group to the delegate type. This conversion checks that the method's signature matches the delegate's signature. Be careful with overloaded methods; the compiler will choose the overload that best fits the delegate's signature. If ambiguity occurs, you can cast explicitly:

Operation op = (int x, int y) => Add(x, y); // explicit lambda avoids ambiguity

Method group conversions work with Action and Func as well. For example, if you have a method void Print(string message), you can pass it to a List.ForEach method:

List<string> values = new List<string> { "a", "b" };
values.ForEach(Print);

The compiler knows that Print can be converted to Action<string>.

Passing Methods to Asynchronous Methods

Delegates also play a role in asynchronous programming, especially when you need to invoke a method later or on another thread. For instance, the Task.Run method accepts a Func<TResult> or Action. You can pass a long-running method as follows:

Task<int> task = Task.Run(() => ComputeExpensiveResult());

You also see delegates in callbacks for operations like HttpClient's response handling, though modern code often uses async/await instead. Passing methods as parameters remains a foundational pattern for threading and continuation-based code.

Avoiding Common Pitfalls

One common issue is capturing loop variables in lambdas. If you create a lambda inside a for loop and pass it to a method that stores it for later invocation, the lambda captures the variable, not the value at creation time. This leads to surprising bugs:

List<Action> actions = new List<Action>();
for (int i = 0; i < 3; i++)
{
    actions.Add(() => Console.WriteLine(i));
}
foreach (var action in actions)
{
    action(); // prints 3,3,3
}

To fix, copy the loop variable to a local inside the loop:

for (int i = 0; i < 3; i++)
{
    int current = i;
    actions.Add(() => Console.WriteLine(current));
}

This is not a language limitation but a subtlety of variable capture. Understanding this helps you avoid subtle behavior changes.

Another pitfall is overusing delegates for every call site. If a method simply needs to execute a single fixed operation, passing a delegate introduces an extra layer of indirection that may obscure the control flow. For example, instead of passing a delegate to a method that calls it immediately, consider making the method accept concrete data and return a result. Delegates are best for scenarios where the operation is dynamic, such as user-selected actions or plugin-style architectures.

Performance and Allocation Considerations

Passing methods via delegates does incur a small allocation when the delegate is created, especially if it captures state. In performance-critical loops, this can add pressure on the garbage collector. Modern .NET optimizations like caching delegate instances can mitigate this. For instance:

private static readonly Func<int, int> _double = x => x * 2;

This reuses the same delegate instance across multiple calls. However, for most business applications, the overhead is negligible. The real cost is often readability and maintainability rather than runtime speed.

When measuring performance, rely on profiling rather than intuition. If you have a hot path that repeatedly passes anonymous methods, test whether caching the delegate changes observable metrics.

When a Delegate Is Not the Right Abstraction

Delegates are not the only way to pass behavior. Interfaces allow you to encapsulate related methods and maintain state. For example, if you need both a Execute method and a Rollback method, an interface like ICommand may be cleaner than passing two delegates. Also, reflective approaches or dynamic invocation exist but should be avoided due to loss of type safety and runtime overhead.

Choose the simplest approach that fits your design. If you only need a single callback, a delegate is concise and clear. If you need a set of operations that share state or need to be swapped together, define an interface or an abstract class.

Extending the Pattern: Returning Methods

A natural extension is to return a method from a method. For example, a factory that returns a comparator:

public static Func<int, int, int> GetSubtractor()
{
    return (x, y) => x - y;
}

This can be useful for creating specialized operations at runtime. However, do not over-engineer. If a simple switch statement inside the method is clearer, use that instead.

Integrating with Events

Events are a special form of delegate. When you write event EventHandler MyEvent;, you are declaring a multicast delegate that can hold multiple event handler methods. Passing method references to event subscriptions is exactly the same syntax:

button.Click += OnButtonClick;

Be careful to unsubscribe from events when you no longer need them to prevent memory leaks, especially if the event source outlives the subscriber.

Final Code Example: A Reusable Try-Catch Wrapper

To bring these concepts together, consider a method that wraps an operation in error handling and returns a default value on failure:

public static T ExecuteWithFallback<T>(Func<T> operation, T fallback)
{
    try
    {
        return operation();
    }
    catch (Exception)
    {
        return fallback;
    }
}

// Usage
var price = ExecuteWithFallback(() => GetPrice(productId), 0);

This general utility avoids duplicating try-catch blocks throughout your codebase. The Func<T> parameter captures the operation, and the fallback value is supplied separately. Note that catching all exceptions may hide serious, non-recoverable errors, so use this pattern with care in production; you might catch only specific exception types.

By understanding how to pass methods as parameters, you can write code that is both reusable and expressive. The key is to recognize when a delegate provides a clean boundary between the caller and the behavior being invoked, and to avoid overusing it where simpler control flow would suffice.