In Search of Maybe in C# - Part III

Following up on the last two posts[1, 2] this final post in my little series on Maybe/Option gives a third implementation of Option. This time around I'll drop the idea of letting Option implement IEnumerable and instead focus on implementing the function needed to make my Option a monad (which it wasn't actually in the last post).

First off let's reiterate the basic implementation of Option - a simple class that can be in two states 'Some' or 'None', where Options in 'Some' state contain a value and Option in 'None' state don't.

I also want to maintain the matching functionality that I had  in the other posts, so I'm keeping this:

While even this is somewhat useful as is, it becomes better if we add the remaining part of the monad; the FlatMap function (the unit function is the Some(T value) method, so only FlatMap aka Bind aka SelectMany is missing). So we add this to the OptionHelpers class:

This is nice because now we are once again able to chain operations without having to worry much about null ref exceptions.
Just for convenience I'll throw in a Filter function in the OptionHelpers as well:


To exemplify how Option can flow through a series of operations take a look at the following where there is a value,so the some case will flow through:

In the case of no value the none case will flow through as in this example:



Towards the end of the first post in the series I mentioned that it's nice to be able to treat Option as a collection. That led to Option implementing IEnumerable in the second post, thus enabling passing Options into existing code working on IEnumerables, which is quite useful when introducing Option into an existing code base. Especially so, if it's a code base that uses LINQ a lot. In such code you're likely to find functions accepting an IEnumerable and returning an IEnumerable. An Option type implementing IEnumerable fits rigth in. On the other hand, if you don't have exiting LINQ based code to fit into, the Option version in this post is maybe a bit simpler to work with because it has smaller API surface and it still provides the benefit of allowing chaining.

In Search of Maybe in C# - Part II

In my last post I wrote that I'd like to have an implementation of the Maybe monad in C#, and I explored how to use the F# implementation - FSharpOption in C#.

In this post I'll show a quick implementation of Maybe in C#, I'll call it Option - as was noted in some of the comments on the last post this turns out to be quite simple. I left off last time mentioning that it's nice when Option can act somewhat as a collection. That turns out to be easy too. Just watch as I walk through it.

Implementing basic Option
First of all the Option type is a type that can either be Some or None. That is simply:


which allows for creating options like this:


So far so good. This all there is to a basic Maybe monad in C#.

Simulate pattern matching on Option
As argued in the last post I'd like be able to do something similar to pattern matching over my Option type. It's not going be nearly as strong as F#s or Scalas pattern matcing, but it's pretty easy to support these scenarios:


All that takes is adding to simple methods on the Option type that each check the value of the Option instance and calls the right callback. In other words just add these two methods to the Option class above:


That's matching sorted.

Act like a collection
Now I also want Option to be usable as though it was a collection. I want that in order to be able to write chains of linq transformations and then just pass Options through that. To illustrate, I want to able to do this:


This means that Option must now implement IEnumerable<T>, which is done like so:


And to be able to get back an option from a IEnumerable with 0 or 1 element:


which is useful in order to be able to do the matching from above.

All together
Putting it all together the Option type becomes:


Not too hard.

In Search of Maybe in C#

One of the things working in Scala has taught me about C# is that the maybe monad is nicer than null.

In case you're not sure what the maybe monad is: It's a generic type that either contains a value or not. In Scala as well as in F# this type is called Option and can be either Some - in which case it contains a value - or None - in which case it doesn't. This allows you to represent the absence of a value in an explicit way visible to the compiler, since Option<T> is a separate type from T. This turns out to be a whole lot stronger than relying on null to represent the absence of a value. I'll point you to an article about F#'s Option for more explanation on why.

Functional languages will usually let you pattern match over Option, making it very easy to clearly differentiate the case of Some from the case of None. In F# this look like so:


In C# we don't have this. The closest thing is Nullable<T>, but that doesn't work over reference types. But is Nullable<T> really the closest thing in C# to Option? - NO. As was pointed out to me in a recent email exchange the F# Option type is available in C# too.

Let's see if we can redo the above F# code in C#. First the declaration the name variable:


The F# Option type is part of the FSharp.Core assembly and the is actually called FSharpOption. Hence the line above.
On to the nameOrApology variable:


Not nearly as clear as the F# counterpart. What's in the if part; what's in the else part. Not nearly as clear to me as the pattern matching in F#.
We can do better, using this little helper extension function:


Which let's us initialize nameOrApology like this:


Now the two outcomes - a value inside the Option or no value - are much more clear to me.

This is OK. Although the name, FSharpOption, is not too nice. Some of the method names - e.g. get_IsSome - aren't nice either. More importantly: Another thing Scala taught me is that it's nice if Option can be used in place of a collection. But that's for another post.

More OO Around That Island of Functional

In my last post I showed how C# seamlesly supports having little functional islands inside an otherwise OO code base. I did that using a simple object model, in which one of the objects was implemented in a functional manner. The other objects, though, were just data containers, really.In that post I made the off hand remark that these could be better encapsulated. In this post I'll address this, and also show that the "other" objects could easily have more behavior as well. All-in-all this brings the example closer to the original intention: To show how the overall design can be OO, but the insides of individual classes can be functional.

The classes involved were CourseTemplate, Course, Registrant and CoursePlan. The example is to create a course plan, where registrants are placed in in courses bsed on which course they wish to take.

Slightly Better Encapsulation

To get to a more object oriented design the first step is to move away from simple auto properties with public getters and public setters to a least have private setters. Using CourseTemplate as an example this simply means moving to this:

Adding Basic Domain Operations

Nest step is to start adding basic domain operations that make the objects have just a little bit of actual behavior and some more encapsulation. To illustrate lets add a method for wishing courses to the Registrant class, and lets also add an override of equals that makes more sense from a domain perspective:

Adding other Behaviors

We're getting the hang of this. Let's add the same type of basic domain methods along with a few other (made up) methods to the Course class:

By adding Register, IsFull and IsEmpty some responsibility is being moved from the CoursePlan version in the last post to the Course - which makes much more sense. By adding Start and AwardDiplomas I point toward the fact that these classes can have more behavior if we need it.

The Functional Island is Still Functional

Despite these changes the CoursePlan doesn't change all that much. The places the implementation has changed is where the new methods on Course are used. The implementation is still just as functional:

Conclusion

The functional islands I talked about in the last post can easily exist in a truly object oriented code base.

On Functional Islands in Obejct Oriented Code

This post is a comment on some of how Brian Marick outlines how to embed functional code in a object oriented code base in his book "Functional Programming for the Object-Oriented Programmer". An excellent book for anybody moving into FP from OO, by the way. I definitely recommend it.

TL;DR

I feel that the best way to embed functional islands in an OO code base is to have certain classes be fully OO on the outside and as functional as you can get them on the inside. Doing so in a multi-paradigm language like C#, the bridging between the OO realm and the FP realm can become seamless.

Functional Islands

Brian uses a drawing like this one in his book to explain that functional code can live within an OO structure, and can be used by the OO code via a couple of bridges; one transforming an object graph to a data structure more suitable for the functional code, and one doing the opposite transformation. This bridging is done because functional code tends to work more on data than on objects - typically contained in general data structures like lists or sets. 

This makes sense; the OO world has one way of modeling and the FP world has another way. To move between them some bridging is needed. The book goes on to show an example of this, where some Java code calls into some Clojure code. But before and after the functional Clojure code runs, the bridging occurs. Each bridge is simply a Java method that does the required transformations; simple but tedious code.

I can sort of recognize this pattern from my own C# code, but only sort of. What I usually have when I embed functional code in otherwise OO C# code is that certain classes expose an OO interface to the rest of the code base, but are implemented in a functional style. To demonstrate this I've taken the example from Brians book and sketched in C#.  The rest of this post walks through that code.

Example

The example i: Given a number of courses that run either morning or afternoon, a fixed number of intructors that can teach any course, and a number of registrants that have wishes for which courses they want to attend find a solution.

First off here is the C# code for the OO strucutre Brian uses in his book:

just a few stupid classes - these should probably be better incapsulated, but that is not really the point here.

The solution I want to end up with should be an instance of this class:

To get there the CoursePlan class is used. This is the class that is implemented in a functional style - or to be honest a somwhat functional style: It represents its state as a couple of lists, and does it's work by applying functions to these lists. Moreover it uses functions that work lazily. That's functional. On the other hand is mutates the state of objects inside it lists. In other words it has side effects. Not so functional. All in all I thinks it's fair to say CoursePlan is implemented in a functional style.

To use CoursePlan I do this:

I just create a new CoursePlan and pass in a course list, registrant list and the number of instructors. Notice the CourseList and RegistrantList? -Those are domain specific collections. By which I mean domain objects like any other that happen to implement the domain notions of "a list of courses" and of "a list of registrants". Having such domain specific classes instead of List<Course> and List<Registrant> in my experience leads to cleaner OO code, and is something I usually advocate.

So where does the bridging from OO to FP go on? Well that's the point it's almost not there: The bridging is taken care of simply because the two domain specific collections - CourseList and RegistrantList - implement IEnumerable<Course> and IEnumerable<Registrant> respectively.

The code for CoursePlan is pretty trivial, but here you go anyway:

Conclusion

In conclusion I feel that the best way to embed functional islands in an OO code base is to have certain classes be fully OO on the outside and as functional as you can get them on the inside. Doing so  in a multi-paradigm language like C#, the bridging between the OO realm and the FP realm can become seamless.

A Pinch of Functional in my C# - An Everyday Example

I'm working on a codebase that, like many other code bases,  has a number of data access objects(DAOs) that all inherit a common superclass. The other day I got tired of looking this pattern of code repeated a lot in the DAOs:

    1        public MyDTO GetMyDTO(...)

    2         {

    3             DataContext DB = NewDBContext;

    4             try

    5             {

    6                 DB.Connection.Open();

    7                 //Fetch something from the DB and return it

    8             }

    9             finally

   10             {

   11                 if (DB.Connection.State == ConnectionState.Open)

   12                     DB.Connection.Close();

   13             }

   14         }

I wanted the creation of the DBContext and the handling of the connection to be factored into somewhere reusable. So I applied the functional "suround with" pattern and introduced this method in the superclass:

    1        protected TReturn UsingDBConnection<TReturn>(Func<DataContext, TReturn> func)

    2         {

    3             DataContext DB = NewDBContext;

    4             try

    5             {

    6                 DB.Connection.Open();

    7                 return func(DB);

    8             }

    9             finally

   10             {

   11                 if (DB.Connection.State == ConnectionState.Open)

   12                     DB.Connection.Close();

   13             }

   14         }

and the DAO code then turns into this:

    1        public MyDTO GetMyDTO(...)

    2         {

    3             return UsingDBConnection(DB =>

    4             {

    7                 //Fetch something from the DB and return it

    7             });

    8         }

C# has supported this for years now, so why am I posting it? -Because I wish I saw more of this type of code. To me it's easy to read and I get to reuse the common part.