Friday, August 07, 2015

OK, that’s a provocative title to get your attention. This post is really about how one can move to a more functional programming style and remove the need for much of the apparatus of object-oriented programming, including interfaces and classes. In this post, I’m going to take some typical object-oriented C# code and refactor it in a more functional style. I’ll show that the result is more concise and easier to test.

Over the past couple of years I’ve noticed that my C# coding style has changed drastically under the influence of functional programming. Gone are interfaces and instance classes to be replaced by static methods, higher-order functions and closures. It’s somewhat ironic since I spent many years as a cheerleader for object-oriented programming and I considered static methods a code smell.

I guess if I look at my programming career, it has the following progression:

Procedural –> Object-Oriented –> Functional

The OO phase now looks like something of a detour.

C# has all the essential features you need for functional programming – higher-order functions, closures, lambda expressions – that allow you to entirely ditch the OO programming model. This results in more concise, readable and maintainable code. It also has a huge impact on unit testing, allowing one to do away with complex mocking frameworks, and write far simpler tests.

Introducing our object oriented example

Let’s look at an example. First I’ll introduce a highly simplified OO example, a simple service that grabs some customer records from a data-store, creates some reports and then emails them. Then I’ll show the same code refactored in a more functional style using delegates and higher-order static methods.

Let’s look at the object-oriented example first:

Well written object-oriented code is compositional. Concrete classes depend on abstractions (interfaces). These interfaces are consumed as dependencies by classes that rely on them and are usually injected as constructor arguments. This is called Dependency Injection. It’s good practice to compose object instances in a single place in the application - the composition root - usually when the application starts up, or on a significant event, such as an HTTP request. The composition can be hand coded or handed off to an IoC container. The constructed graph is then executed by invoking a method on the root object. This often occurs via an application framework (such as MVC or WebApi) rather than being explicitly invoked by user code.

We are going to get some customer records, create some reports and then email them to our customers. So first we need three interfaces: a data access abstraction, a report building abstraction, and an emailing abstraction:

And here are the implementations. This is not a real program of course, I’ve just coded some dummy customers and the emailer simply writes to the console.

Now we have our service class that depends on the three abstractions and orchestrates the reporting process:

As you can see, we inject the dependencies as constructor arguments, store them in class properties, then invoke methods on them in the code in the RunCustomerReportBatch method. Some people like to store the dependencies in class fields instead. That’s a matter of choice.

Our composition root composes the ReportingService with its dependencies and then returns it for the program to invoke. Don’t forget this is a highly simplified example. Composition is usually far more complex:

To write a unit test for the reporting service we would typically use either hand-crafted mocks, or some kind of mocking framework. Here’s an example unit test using XUnit and Moq:

We first create mocks for ReportingService’s dependencies with the relevant methods stubbed, which we inject as constructor arguments. We then invoke ReportingService and verify that the emailer was invoked as expected.

So that’s our object-oriented example. It’s typical of much well constructed C# code that you will find in the wild. It’s the way I’ve been building software for many years now with much success.

However, this object-oriented code is verbose. About a third of it is simply OO stuff that we have to write repeatedly and mechanically rather than code that is actually solving our problem. This boilerplate includes: the class’ properties (or fields) to hold the dependencies; the assigning of constructor arguments to those properties; writing the class and constructor. We also need complex mocking frameworks simply to test this code. Surely that’s a smell that’s telling us something is wrong?

Enlightenment

Enlightenment begins when you realise that the dependencies and method arguments can actually just be seen as arguments that are applied at different times in the application’s lifecycle. Consider a class with a single method and a single dependency:

We could equally represent this as a static method with two arguments:

But how do we partially apply these arguments? How do we give ‘DoThing’ the IDependency argument at composition time and the ‘string arg’ at the point where it is required by the application logic? Simple: We use a closure. Anything taking a dependency on ‘DoThing’ will ask for an Action<string>, because that is the signature of the ‘Do’ method in our ‘Thing’ class. So in our composition root, we ‘close over’ our previously created IDependency instance in a lambda expression with the signature, Action<string>, that invokes our DoThing static method. Like this:

So the interface is replaced with the built-in Action<T> delegate, and the closure is effectively doing the job of our ‘Thing’ class, the interface’s implementation, but with far fewer lines of code.

Refactoring to functional

OK. Let’s go back to our example and change it to use this new insight. We don’t need the interface definitions. They are replaced by built in delegate types:

ICustomerData becomes Func<IEnumerable<Customer>>

IEmailer becomes Action<string, string>

IReportBuilder becomes Func<Customer, Report>

The classes are replaced with static methods:

Our ReportingService is also replaced with a single static method that takes its dependencies as delegate arguments:

Composition looks like this:

This is functionally equivalent to the object-oriented code above, but it has 57 lines of code as opposed to 95; exactly 60% of the original code.

There’s also a marked simplification of the unit test:

The requirement for a complex mocking framework vanishes. Instead we merely have to set up simple lambda expressions for our stubs. Expectations can be validated with closed over local variables. It’s much easier to read and maintain.

Moving to a functional style of programming is certainly a huge departure from most C# code that you find in the wild and can initially look a little odd to the uninitiated. But it has many benefits, making your code more concise and easier to test and reason about. C# is, surprisingly, a perfectly adequate functional programming language, so don’t despair if for practical reasons you can’t use F#.

...one of the consequences of SOLID is that you should favour Role Interfaces over Header Interfaces, and as I've previously explained, the logical conclusion is that all interfaces should only have a single member.

When interfaces only have a single member, the interface declaration itself tends to mostly be in the way - the only thing that matters is the operation. In C#, you could just use a delegate instead, and even Java has lambdas now.

...

In my experience, you can model everything with single-member interfaces, which also implies that you can model everything with functions.

Totally agree with you but there's something I see as a problem, and let me do a little strechy analogy here, moving from OOP to Functional feels like moving from Typescript back to JavaScript, I'll explain in just one second:

IEmailer becomes Action

problem with this is: IEmailer and its method Send(string toAddress, string body); are very, extremely, explicit about what they mean and do, we all agree here

whereas Action is completely meaningless other than it's a function that received 2 string parameters and returns void. What parameters, what do they mean?

I'm sure we all can imagine different, simple ways of solving this issue with trivial language features, but they don't exist yet, in C# at least.

IEmailer is just a typedef (essentially) for an interface about a function that takes some strings and sends an email. There are functional equivalents of that, renaming to reduce a developer's cognitive load. I'm not sure what it would be in C# (I'd be surprised if there wasn't an equivalent way), but in Haskell it would look something like:

type Address = Stringtype Body = String

type Emailer = Address -> Body -> Email

Where here Emailer is the type that represents a function that takes an Address and a Body and returns an Email. I could probably have chosen the names better, but hopefully you get the idea.

I like this. I don't think technicalities pose a stumbling block to anyone trying to adopt this style. I take @Ricardo's point. I would say that you would aim to minimize the occasions when you have to resort to the action. Typically it would be when performing operations that have side effects. Ideally you want to keep those at the edges of the application. The core can be built in functional style where each function takes some input and yields some result. The stumbling block would be the recognition of the advantages of the style. This is harder to prove and I think this is one of the reasons functional programming in general hasn't become mainstream outside certain circles. People can easily counter the fact that the code base has shrunk by 40%. Personally I favour this style and I would try it in C#. Ultimately as others have said F# should be at least considered if we're targeting .NET. I'm currently learning F# and Haskell and I'm loving it. I'm beginning to think that people are wired differently. As Mark Seeman (and also stated here) certain constructs seem to get in the way of what you are trying to express. I value clarity, simplicity, less moving parts, referential transparency, idempotency, declarative style which I think you get from a more functional style.

Okay. I've just had a thought and I've found this http://bit.ly/1MSjnFd on StackOverflow. Essentially we could improve this by having alias for your function specifications. It's a bit left-field but perfectly valid. In some ways it still exposes C# as object oriented and functions tagging along in the trailer :-). So you could say

using Emailer = Action;using CustomerRetriever = Func>;

Perhaps poor naming convention but you can see that there is a path back to the goodness of types and the expressiveness and compile time guarantees they offer.

I don't think that's a good option, 2 different aliases won't work I believe.That SO reference also proves my point. There's too much ceremony in trying to port this functional behavior in C#, the language just doesn't support it yet (if it ever will).

@Ricardo Rodrigues: Exactly. I think it is at the point where the level of ceremony and cumbersomeness becomes unbearable that people consider a functional first or even a "pure" functional language ;-)

having said that a lot has been achieved with imperative and object oriented programming. It'll probably be with us for a while. All roads lead to Rome as someone said :-). Perhaps its more about the journey.

It's an interesting idea. I wonder how it will scale, though, to a real-world application of significant complexity. Also, I have to disagree on test simplification. You could actually construct the unit test almost exactly the same way with Moq, with no extra complexity or lines of code.

If you go that style you could switch to F# - it's that you're missing stuff you need in more complex scenarios. Stateful functions? Currying instead of ctors. Just think about the fact that Action and Function are two distinct types. You are also missing algebraic data types. What you have now is a language with some functional elements, basically a subset of the whole language.

I'd be interested to hear why all your interfaces (and classes) only have one method, and whether cohesion ends up suffering? I have worked on similar codebases and find the classes too small and disconnected, with dependencies difficult to follow and code difficult to track down, not to mention unit tests all need reshuffling every time the dependency graph changes, and algorithms being split over multiple classes and functions even to do something simple.

Personally I would consider moving in the other direction - not to start using static methods, but look at consolidating the classes towards better cohesion and encapsulation. I recently changed 6 classes into 2, and the code was much cleaner. (A provider, a factory, a factory-factory, a repository...)

Another thing I've noticed is that I actually have remarkable trouble refactoring such "micro-class" codebases - in my experience it seems to be much easier / more natural to break up a large class than reassemble many small ones.

Did you do any performance profiling you can share? I'm interested in the runtime behavior of such conversions; lots of discussion of functional variants either ignore performance or the functional version is slower due to increased (hidden) looping and memory related to functional collection related thinking.

I've enjoyed the recent tech du jour focus on functional languages, but I also am suspicious there's a reason why they have been around forever (i.e. Lisp in 1958) but always just a niche. Performance seems to be one thing keeping it there.

I was going to complain about how bad and pointless the interfaces were in your starting code but then realized it's a great example of real world. Totally pointless interfaces that offer nothing and don't need to exist.

@Ricardo Rodrigues the purpose of TypeScript isn't to make javascript less functional the purpose is to fix the insanity of how bad it is at handling contracts. It also adds meta programming (which some/all is being absorbed by ES6 because of the major lacking of it in JS)

If you had an INotifier with an email implementation and something else, a truly needed encapsulation for data storage (other than a database? EF itself already is an abstraction), and more than one type of reporting services, I'd go with all the interface and all.

To be very straight to the point: I see a lot of code with interfaces that are realized by only one type of object and it's useless. Many people code with the "what if" syndrome and that's waste of time.

This is a journey I've been on for a long time. Initially, bastardizing an OO language to work functionally feels like a nice thing to do.

And then you realize that you are writing little functions everywhere to glue things together (like your compose function).

So, you write a library of little combinators, such as the ones given in the answer to http://stackoverflow.com/questions/5264060/does-c-sharp-support-function-composition.

You then realize that you could combine things so much better if you had partial application. And then you write some more little combinators.

So much boiler-plate. When will it end?

Then one day, the new person joins the team and they immediately spew as they see the crazy. You slowly open your eyes and realize that you can't put lipstick on a pig; C# ain't functional.

My point is you can't turn a language into something it's not. C# is a great language, but it lacks some vital pieces to be an effective functional language (partial application is probably the biggest for me, but there's many more). Functional-esque C# is just a gateway drug to a functional language.

I don't agree with the "complex mocking framework" part. There's no added complexity to the first test as in additional abstraction layers, messy conditional logic or dirty technical tricks. Of course the mocking framework brings new vocabulary to the equation, but the semantics of "setting up" a context for the system under test and "verifying" stuff are naturally lurking in the test between the lines anyway, you might as well make them explicit.

So to me the two implementations are equally readable, with the OO version maybe a little more intention-revealing thanks to "Verify( a method was called...)" and "Setup". But sure, you could be exactly as expressive in the functional version with some well-named helper functions.

Anyway, a very good article about the functional approach to dependencies and testing.

Using named delegates to make it explicit what a Function is for can be harmful to your career - I recently received the following feedback from an offline coding test I had to submit when going for a contract (which I didn't get).

"When using Funcs<> from 3.5 I would expect not to use delages cira 2.0 mixing these sort of stuff is a red flag for me. would expect to use Actions instead of delegates"

Looks interesting. Can you please do a followup post where your interfaces have say 3-4 methods each? I'm not really sure how your approach scale, hence why I'd like your take on a more realistic situation.

@James, seriously? You group code in classes and interfaces in OOP, you group code in modules in FP. Please don't bring forward the rantings of a mad man in the discussion - or accept that code that does something (accessing db (fetch/store), going to external providers etc. will end up with 8+ dependencies with that kind of thinking. And carrying around 8+ function pointer arguments will make your code brittle and confusing to say the least.

Just found this post and have to agree. Over the past few years I have been moving more into the functional space with C#. As for does it scale, I can answer yes. I work on a project that is about a decade old so parts are in all flavors of C# from V2 onward. Most of the new stuff has been functional and it is cleaner, more consice and far easier to refactor because of it.

The more I use functional the more I believe OO is a dead end and a productivity time suck. It simply does not give the fluidity of code that functional provides.

Just look at your old code, if you have interfaces that have one method the question should be why, just a bunch of pointless noise. An interface, a class and possibly IOC registration and resolution.

People used to worry about readonly dictionaries in C# but I just pass around a Func which is the lookup and also means you are not even tied to a dictionary.

Functional, because you break everything down more, gives more building block with finer granularity and closures provide far more power and flexibility that classes can.

So the current project has 500000 lines of C# and I can work faster and move faster in the functional stuff than I can in the OO

My career has followed a similar trajectory. I was all on board with OO in C#, until one day the fancy features of F# aroused my curiosity. I spent many months diving head first into that language in my off time, and I found that I didn't care half so much about its fancy features as I did the style and paradigm of the language. Following that, my C# code has never been the same.

I was recently asked to join a new, multi-division project, and I brought my functional style with me. I was expecting some push back, but much to my surprise, I have been showered with praise. Brilliant, masterpiece, top gun coder, etc are all being tossed around. No, functional programming is brilliant, and one can do some genuinely brilliant things with it. I just use the stuff.

There are a couple dinosaurs in the project, but rest assured that I will convert them. The level of code reduction, readability, and stability gained is so immense--the productivity so enhanced--they will not be able to resist forever. And to any dinosaurs out there reading this comment, you will be assimilated. Resistance is futile.

Action and func are just templates for delegates. A delegate is effectively a method signature and analogous to an interface with a single method. So i'd be inclined to agree with using delegates over action/function as it is more expressive. This article is thought provoking which is great and static methods should offer performance improvements to some extent but f# immutable types offers thread safety which hasn't even entered this discussion. Great article.

Nice write up. Far easier to maintain Functional and Procedural code vs OOP. The advantages of OOP have been exaggerated for years. Let's face facts regarding time, money, manpower, budgets. The code is built once and maintained for years. Good Code all ways ends up being about about EASE of maintenance. Functional and Procedural coding is making a comeback for good reason.

This is very helpful because I find myself slowly converging on the same pattern. I often write classes with one or two dependencies, and they tend to be small and stateless. The dependencies themselves also often have one method. (I've recently leaned toward injecting delegates instead of interfaces, partially for that reason.) So the pattern you demonstrated of replacing the class with a method and replacing the injected dependency with an argument is perfect.

Going a step further, when I inject a dependency I tend to use only one method. So the next logical step is for the method to take a delegate as an argument instead of an interface or class.

One thing I like about this approach is that it makes it more difficult for someone to clutter the code. They can't sneak in new class dependencies by adding new members to existing interfaces.