I work for a company that has multiple sites across Europe. I recently came across a problem where we had a single application that needed to be installed in each office, but each country’s workflow is slightly different. The solution was to have a separate class for each country and to inject the correct class at runtime. However, we use the “build once, deploy many” strategy which meant we couldn’t use DI in the traditional manner. I’ll elaborate on this point below.

This is the 3rd part in my series of applying Functional Programming principles in C#. Functional Programming is naturally expression-based; almost everything produces a result. With regards to C#, although many of its programming constructs are statement based, it does provide a number of operators we can use instead of statement-based alternatives.

In my last post I mentioned we should try to reduce side-effects in our functions. One of the easiest ways to do this is to enforce immutability.

Following on from my brief overview of Functional Programming, this is the first in a series of blog posts describing how to make use of FP principles in C#, and hopefully make your projects more predictable, reliable, and maintainable.

I’ve been reading about Functional Programming for many years, but as I don’t code in a functional language such as F# or Haskell, I’ve not really had the chance to see how I can make use of FP principles. Fortunately, as work slows down for the Christmas holidays I’ve now found some spare time to revisit this topic. In this post I’ll give a general overview of FP, and then in future posts I hope to describe how to apply FP principles to C# (my primary language).