Who follows me from the beginning perfectly knows my obsession for the dependency management in programming languages. I have already written of dependency injection mechanisms in modern programming languages. In Eat that cake! I wrote about the Cake Pattern and how to use Scala self types to resolve the problem of dependency injection. In Resolving your problems with Dependency Injection, I introduced the problem of the dependency resolution. In Resolve me, Implicitly, I showed how to use Scala
implicits to implement a dependency injection mechanism. Now its time to speak about how functional programming tries to solve the dependency management issue, using the Reader Monad.
Imagine you have a type whose responsibility is to manage the persistence of stocks information. Let we call it
StockRepository. The repository can retrieve all the stocks present in a wallet, can sell a quantity of a stock or can buy some amount of stock. It follows the definition of such a type.
The repository implements what we can call persistence logic.
Then, we have a type that uses the
StockRepository to give to its clients some business logic built upon the above persistence logic. Let’s call it
Stocks. Imagine that we want to give access to the three functions of the repository, plus a fourth function that invest money in the stock that has the lowest quotation.
sell(stock: String, quantity: Double)
buy(stock: String, amount: Double)
Stocks has a dependency upon
StockRepository. How can we express such fact in the code? We don’t want to use the constructor injection mechanism or anything related to it. We want to stay functional.
Dependency management within functions
The trivial solution
An option is to pass a reference of the repository to each function that need to access to its methods.
This trick does its dirty job, but it pollutes the signature of each function that needs some external dependency. Our example has only one dependency, but in real life, dependencies are often more than one.
Using currying to isolate dependencies
The currying process can help us to make things a little better. Imagine isolating the dependency parameters using a curried version of the previous functions.
As you know, the currying process allows us to partially applied a function, obtaining as the result of the partial application a new function with fewer inputs.
In mathematics and computer science, currying is the technique of translating the evaluation of a function that takes multiple arguments into evaluating a sequence of functions, each with a single argument.
Let’s take an example.
Let the function
def add(a: Int, b: Int): Int = a + b that adds to integers. If we apply currying to the function
add we obtain the following new function.
The return type of the function
add is not anymore a pure
Int but now it is a function from
Int => Int.
If we apply the currying reasoning to the functions of the
Stocks module, we obtain the following definition.
We remove the ugly
StockRepository parameter from the signature of our function! Yuppi yuppi ya! However, it is complicated to compose functions with the last signature we had :( Imagine that we want to implement the function
investInStockWithMinValue using the function we developed so far. A possible implementation is the following.
It is not simple to follow what is going on. The use of the function
andThen does not help the reader to understand the main workflow of the function, because it is not semantically focused on the operation it is carrying on. Moreover, in the last line, there is a very ugly function application,
Stocks.buy(s, amount)(repo) that waste our code with a detail that is not related to the business logic but only to the implementation.
We can do better than this. Much better.
The Reader monad
What if we encapsulate the curried function inside a data structure? Using such an approach is precisely the idea behind the Reader Monad.
We have our function, let’s say
f: From => To, where
To are respectively the starting type (domain) and the arriving type (codomain) of the function. As we just said, we put a data structure around our function.
We want to apply in some way the function enclosed inside our data structure. We add the application function.
To improve the readability of our code, we want to have a function different from
andThen to compose a function
f. Given a function
g: To => NewTo, we need a function to compose
f inside a
Reader. This function is called
flatMap function composes
f with functions
z: To => Reader[From, NewTo]. This function is equal to the last application of the
andThen method in our previous example.
In other words, the
flatMap function serves to compose two functions sharing the same dependency. In our example, using a
flatMap, we can compose the functions
buy both sharing the dependency among a
StockRepository. Using a simple
map, we would obtain the nesting of a
Reader into another
Quite annoying. Using a
flatMap, instead, we can flatten the result type, and everything goes ok. The function application in the
flatMap definition does the trick.
Finally, we need an action to lift a value of type
To in a
Reader[From, To]. In other words, we want to be able to create from a value of type
To a function that receives a value of type
From and returns a value of type
To. This function is not a member of the
Reader monad itself. It is more like a factory method.
Reader type is something similar to the following.
It happens that the type
Reader satisfies with its functions
flatMap the minimum properties needed to be a monad. The description of the monad laws is behind the scope of this post.
Moreover, because of the presence of the function
flatMap, we can use the type
Reader in a fashion way to simplify our code.
Finally, using the monad
First of all, we change the
Stocks type with the
As you can see, every direct dependency was removed and substituted with the
Reader[StockRepository, _] type.
Now, it’s time to return to our previous
investInStockWithMinValue function. Using the methods we defined on the monad, we can rewrite the function as follows.
Using the syntactic sugar available from the Scala language, we can rewrite the above code use a for-comprehension statement.
I love the for-comprehension construct because it is self-explanatory :)
Who is responsible for resolving the dependencies, declared through the
Reader monad? The answer is simple, that is the
What if I have more than one dependency?
Very often, we have functions that depend by more than one single dependency. For example, think that you want to add a rate change service to the functions of the
Stock type. Using
RateChangeService, it is possible to buy and sell in a currency that is different from dollars.
The Reader monad we just analyzed handles only one dependency at time. Should we try away all the suitable types we developed until now? No, we shouldn’t. If you depend on more than one type, you can create a new container type, something similar to a context.
In this way, we reduce our function to depend on a single type again, our
Context type. Ball, game, set.
In this post, we analyzed how to declare dependencies in functions. We begin from the simplest possible solution, and we composed step by step a more elegant and practice solution that is called the
Reader monad. Finally, we showed how the monad could simplify the code through the use of the for-comprehension construct.