As you may noticed (if you follow this blog or go to the same conferences as me) I really like the Nancy web framework. So naturally, since I've decided to finally learn F# properly, I threw together a hello world Nancy app in F#. It's very simple; the complete code is listed below. All I did was create an F# console application, install the Nancy and Nancy.Hosting.Self NuGet packages and type in this code, which will return the string "Hello" if you point your browser to "http://localhost:8888/nancy/":
So what's going in that code? Fist thing to notice is the type HelloModule which inherits NancyModule. On start up Nancy will pick up all NancyModules and run their constructor. In it's constructor HelloModule sets up a single route, "/", and tells Nancy what to do on a HTTP GET to that route, namely to execute a lambda that always returns "Hello". Lastly, since this is self hosted, there is a bit of setup in the "main" function: A Nancy host is instantiated, told where to listen for requests and started. This will make the Nancy self host start up Nancy and start listening for requests. That's it. Short and sweet.
Wednesday, March 13, 2013
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:
The functional islands I talked about in the last post can easily exist in a truly object oriented code base.
Thursday, March 7, 2013
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.
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.
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.
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:
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.