After 5 years of object oriented thinking, I’m trying to wrap my head around the functional style of programming. One of the things I had to read over and over before I started to understand them was the concept of Monads. Monads are everywhere in .NET now and it is a foundational concept in many of the really useful libraries and APIs that are coming out of Microsoft (LINQ, Task Parallel Library (TPL), Reactive Extensions (Rx), etc.). One of the simplest implementations of Monads is the Maybe monad.
To help you understand this I took the Maybe<T> implementation from this post by Jordan Terrell. It works with all .NET types; value and reference types.
Let’s have a look at the following simple sample:
Maybe<string> text = Maybe.Value("Hello, World!");
if (text.HasValue)
{
Console.WriteLine(text.Value);
}
text = Maybe<string>.NoValue;At first this seems fairly similar to Nullable<T> with as only difference that it also works for reference types… and you’re right. But using the Maybe monad can lead to a far more elegant solution. One of the advantages of the Maybe monad is that you will never get a null reference exception - it is implemented as a value type (struct) and as such cannot be null. Being able to throw away all my null reference checks throughout my code already makes it worthwhile.
Things get interesting the moment you’re start chaining methods together like in LINQ:
Maybe<Category> parentCategory = Maybe.Value(product) .Select(x => x.Parent);
By using the Maybe monad we can just take the value, if there is one, and selects another value from it. No null checking and no nasty null reference exceptions if the product object didn’t exists.
What’s important to understand? The Maybe monad is a very clean and elegant implementation of the Null object pattern.