|
Functional Programming in C#: The Practical Parts
Read on: my website / Read time: 6 minutes
|
|
|
|
The .NET Weekly is brought to you by:
You know that feeling when you have an idea in your head but can't think of the word for it? Or you have documents in MongoDB Atlas but not the exact text to search them? Vector search might be the answer. Adding MongoDB Atlas Vector Search is pretty straightforward, and can come in handy.
|
Auto-Generate enterprise-grade C# SDKs from OpenAPI specs. Create customizable, strongly-typed C# SDKs with Speakeasy's SDK generator - designed for enterprise APIs where open-source solutions fall short. Compare our SDK generator to popular OSS alternatives and create your first SDK for free.
|
|
|
|
Functional programming patterns can feel academic and abstract. Terms like "monads" and "functors" scare many developers away. But beneath the intimidating terminology are practical patterns that can make your code safer and more maintainable.
C# has embraced many functional programming features over the years.
- Records for immutability
- LINQ for functional transformations
- Lambda expressions for first-class functions
These features aren't just syntax sugar - they help prevent bugs and make code easier to reason about.
Let's look at five practical patterns you can use in your C# projects today.
|
|
|
Higher-Order Functions
Higher-order functions can take other functions as parameters or return them as results. They let you write code that's more flexible and composable because you can pass behavior around like data.
Common examples of higher-order functions are LINQ's Where and Select, which take functions to transform data.
Let's refactor this validation example with higher-order functions:
public class OrderValidator
{
public bool ValidateOrder(Order order)
{
if (order.Items.Count == 0) return false;
if (order.TotalAmount <= 0) return false;
if (order.ShippingAddress == null) return false;
return true;
}
}
Here's how higher-order functions make this more flexible:
public static class OrderValidation
{
public static Func<Order, bool> CreateValidator(string countryCode, decimal minimumOrderValue)
{
var baseValidations = CombineValidations(
o => o.Items.Count > 0,
o => o.TotalAmount >= minimumOrderValue,
o => o.ShippingAddress != null
);
return countryCode switch
{
"US" => CombineValidations(
baseValidations,
order => IsValidUSAddress(order.ShippingAddress)),
"EU" => CombineValidations(
baseValidations,
order => IsValidVATNumber(order.VatNumber)),
_ => baseValidations
};
}
private static Func<Order, bool> CombineValidations(params Func<Order, bool>[] validations) =>
order => validations.All(v => v(order));
}
var usValidator = OrderValidation.CreateValidator("US", minimumOrderValue: 25.0m);
var euValidator = OrderValidation.CreateValidator("EU", minimumOrderValue: 30.0m);
The higher-order function approach makes validators composable, testable, and easy to extend. Each validation rule is a simple function that we can compose.
|
|
|
Errors as Values
Error handling in C# often looks like this:
public class UserService
{
public User CreateUser(string email, string password)
{
if (string.IsNullOrEmpty(email))
{
throw new ArgumentException("Email is required");
}
if (password.Length < 8)
{
throw new ArgumentException("Password too short");
}
if (_userRepository.EmailExists(email))
{
throw new DuplicateEmailException(email);
}
}
}
The problem?
- Exceptions are expensive
- Callers often forget to handle exceptions
- The method signature lies - it claims to return a User but might throw
We can make errors explicit using the OneOf library. It provides discriminated unions for C#, using a custom type OneOf<T0, ... Tn>.
public class UserService
{
public OneOf<User, ValidationError, DuplicateEmailError> CreateUser(string email, string password)
{
if (string.IsNullOrEmpty(email))
{
return new ValidationError("Email is required");
}
if (password.Length < 8)
{
return new ValidationError("Password too short");
}
if (_userRepository.EmailExists(email))
{
return new DuplicateEmailError(email);
}
return new User(email, password);
}
}
By making the errors explicit:
- The method signature tells the whole truth
- Callers must handle all possible outcomes
- No performance overhead from exceptions
- The flow is easier to follow
Here's how you use it:
var result = userService.CreateUser(email, password);
result.Switch(
user => SendWelcomeEmail(user),
validationError => HandleError(validationError),
duplicateError => HandleError(duplicateError)
);
|
|
|
Monadic Binding
A monad is a container for values - like List<T>, IEnumerable<T>, or Task<T>. What makes it special is that you can chain operations on the contained values without dealing with the container directly. This chaining is called monadic binding.
You use monadic binding daily with LINQ, but you might not know it. It's what allows us to chain operations that transform data.
Map (Select) transforms values:
var numbers = new[] { 1, 2, 3, 4 };
var doubled = numbers.Select(x => x * 2);
Bind (SelectMany) transforms and flattens:
var folders = new[] { "docs", "photos" };
var files = folders.SelectMany(folder => Directory.GetFiles(folder));
A popular example of applying monads in practice is the Result pattern, which provides a clean way to chain operations that might fail.
|
|
|
Pure Functions
Pure functions are predictable: they depend only on their inputs and don't change anything in the system. No database calls, no API requests, no global state. This constraint makes them easier to understand, test, and debug.
public class PriceCalculator
{
private decimal _taxRate;
private List<Discount> _activeDiscounts;
public decimal CalculatePrice(Order order)
{
var price = order.Items.Sum(i => i.Price);
foreach (var discount in _activeDiscounts)
{
price -= discount.Calculate(price);
}
return price * (1 + _taxRate);
}
}
Here's the same example as a pure function:
public static class PriceCalculator
{
public static decimal CalculatePrice(
Order order,
decimal taxRate,
IReadOnlyList<Discount> discounts)
{
var basePrice = order.Items.Sum(i => i.Price);
var afterDiscounts = discounts.Aggregate(
basePrice,
(price, discount) => price - discount.Calculate(price));
return afterDiscounts * (1 + taxRate);
}
}
Pure functions are thread-safe, easy to test, and simple to reason about because all dependencies are explicit.
|
|
|
Immutability
Immutable objects can't be changed after creation. Instead, they create new instances for every change. This simple constraint eliminates entire categories of bugs: race conditions, accidental modifications, and inconsistent state.
Here's an example of a mutable type:
public class Order
{
public List<OrderItem> Items { get; set; }
public decimal Total { get; set; }
public OrderStatus Status { get; set; }
public void AddItem(OrderItem item)
{
Items.Add(item);
Total += item.Price;
}
}
Let's make this an immutable type:
public record Order
{
public ImmutableList<OrderItem> Items { get; init; }
public OrderStatus Status { get; init; }
public decimal Total => Items.Sum(x => x.Price);
public Order AddItem(OrderItem item)
{
if (Status != OrderStatus.Created)
{
throw new InvalidOperationException("Can't modify shipped orders");
}
return this with
{
Items = Items.Add(item)
};
}
}
The immutable version:
- Is thread-safe by default
- Makes invalid states impossible
- Keeps data and calculations consistent
- Makes changes explicit and traceable
|
|
|
Takeaway
Functional programming isn't just about writing "cleaner" code. These patterns fundamentally change how you handle complexity:
- Push errors to compile time - Catch problems before running the code
- Make invalid states impossible - Don't rely on documentation or conventions
- Make the happy path obvious - When everything is explicit, the flow is clear
You can adopt these patterns gradually. Start with one class, one module, one feature. The goal isn't to write purely functional code. The goal is to write code that's safer, more predictable, and easier to maintain.
Hope this was helpful. See you next week.
|
|
|
P.S. Quick heads up – I'm putting together a Black Friday deal for all my .NET developers!
You've been getting practical tips every week on everything from software architecture to performance tuning. If you've found value in these newsletters, you'll love what's coming.
So you can hold off on that purchase until the discount is live.
|
|
|
You received this email because you subscribed to our list. You can unsubscribe at any time.
Update your profile | Dragiše Cvetkovića 2, Niš, - 18000
|
|
|
|
|