In the past days I’ve been focusing on learning reactive programming with Spring 5 and while reviewing the example microservice that we create with some friends, we realize how much functional programming we use and how our coding has change since them.
Everyone, in a way or another, understand what functional programming is, we could read the syntax, we could write many lambdas, but the big question is “why?”.
I don’t want to get into enumeration of qualities or get in the usual dogmatic approach about it, this is about code.
Coding is not just syntax, is how we use it to solve problems. I like to show with code how functional programming could help in new ways, at that is what I like to care right now.
All the code posted here is available in this git repo and you could follow the tests incrementally to understand this concepts.
To simplify the code I’ll not use streams, just basically plain Java 8.
Let’s create 3 simple Java methods
Is clear what they do, and we could use it like this:
We know how this work because we have learn that the most interior method, name, is execute first and print last. But of course no one programming things like this, most likely most people will change it to really reflect what we trying to do:
We could just convert those functions to functional method using the Java 8 functions:
The our prints could be just:
Or most likely:
Seriously we don’t see many benefit to use functional interfaces there, just for the sake of use them. That syntax is correct, it uses functional interfaces, but by far is not something that we use to solve problems.
But wait here, we will get there eventually, now just check this class.
Them we could combine it with our functions:
Or even:
This is something that could work. I choose the name Pipe for a reason, be could think in this pattern like the old Unix pipe system, get something in and them get something out.
This is good, but we need still to manage those strange functional interface, what about if we could make them more simple? We can.
Firs we will change our functions as they where at the beginning:
Them we could call them like this:
Or again:
The operator :: will do the magic for us, it will convert our functions in functional interfaces, so our Wrapper still working and we have the benefit to work with standard functions for simplicity.
But to go even further we could generalize our Wrapper like this:
The functions that we are going to use now are:
The we could do many different things with them:
As you could see these allow us to work with any type, any class/object and connect to functions, each of those functions is basically a block, that has a simple input and a simple output but it could be complex and precise, and we pipe them together.
These functions could be unit tested, they could be replace and combine with others in order to create more complex operations, they are really encapsulated.
This as well force us to work with immutable objects since each block create new objects, even our pipes create new wrappers.
Is this really something that we need to use? Not really but is similar to how many of the functional APIs works, including standard and reactive streams.
So to answer the main question: “Why we should use functional programming?”
Not because syntax, not because is trendy, just do it if you could find a useful piece of code that allow you to solve a problem in a way that make sense for you.