Reading my posts you can easily find that there is a topic that cares about me a lot: Dependency management in the development process. There is a feature of the Scala programming language that I liked since the beginning. Without any external library, it is possible to successfully implement vary dependency injection mechanisms. In the past, I wrote about the Cake pattern. Now it’s time to talk about dependency injection through the use of implicits. Let this race starts!
The problem: dependency injection
I have written many times about this topic, then I will not make a long introduction. To summarize, every time a component needs to send a message to another component, a dependency is defined between them. Components may be packages, classes, functions and so on. Messages are always associated with methods or functions calls. Dependency between two components can have many levels of strength. If you want a complete explanation of the dependency concept, have a look at this post: Dependency. For sake of completeness, let’s give an example of the simplest type of dependency: Association.
An association means that a class is made of references to other classes.
Other than the coupling between components that derives from dependencies, the problem with dependencies is also the process that a component has to take in place to resolve them. Dependencies resolution is a complex problem. To treat it successfully, the best thing to do is to apply the divide et impera principle.
Dependency resolution can be divided into two different tasks: dependencies declarations and resolution.
First of all, a component should be able to declare its dependencies. A component should be able to scream “Hey, anybody listening, I need these f@cking classes to work!”. There are many ways a component may choose to declare its dependencies. The most accreditated by the developers’ community is constructor injection.
Using constructor injection, a component declares its dependencies as the parameters of its constructor.
In the above example, the class
Connection is screaming to everyone that it needs an instance of an
ActorSelection class to work properly.
If you want to know which other types of dependency declarations are available, please have a look at the post Resolving your problems with Dependency Injection.
Now that we know how to declare which kinds of objects a component needs to work, we also need a technique to resolve these object. And it’s here that the “injection” part comes into play.
Resolving dependencies in Scala
In the JVM ecosystem, there are a lot of libraries that implement the injection technique. We have many alternatives, such like the following.
- Spring framework
- Dagger 2
There is also a Java Specification Requests dedicated to dependency injection, the JSR 330. As you can see, the JDK needs external libraries to implement the dependency injection mechanism.
But, Scala is different. The Scala programming language has a richer semantic that allows implementing dependency injection mechanisms without the need of any kind of external libraries. As you we will see in a moment, this technique applies both to classes and to functions. That’s awesome!
In the past, I wrote about the Cake Pattern, which implements dependency resolution using traits and self-type. This time I want to write about a dependency injection mechanisms that uses two other features of Scala, function currying, and implicits.
As you know, Scala is also quoted as a functional programming language. Functional programming languages have many nice features. One of these features is function currying.
Let’s take for example a function that takes two arguments:
We can refactor this function into a new one, that takes only one parameter and returns a new function.
To multiply two integers you have to call the last function in the following way.
We said the function
mulOneAtTime is equal to the curried function of the original function
In mathematics and computer science, currying is the technique of translating the evaluation of a function that takes multiple arguments (or a tuple of arguments) into evaluating a sequence of functions, each with a single argument.
There is a shortcut for defining such curried function in Scala:
The languages save us from defining a lot of intermediate functions, giving us some vanilla-flavored syntactic sugar.
I suppose that you are asking why are we talking about currying instead of dependency injection. Be patient.
Implicits are another awesome feature of the Scala programming language. Hated by someone and feared by most, implicits can be applied to resolve a lot of problems, from automatic conversion between two types to the automatic resolution of dependencies. What we are going to explain is how implicit parameters work in Scala.
The parameters of a function (or a method) can be marked with the keyword
implicit. In this case, the compiler will automagically look for a value to supply to these parameters. Here is a simple example of a function using an
implicit parameter, taken directly from the Scala SDK:
In the above example, the parameter
execctx of method
apply is automatically resolved and provided by the compiler to the program. How does the Scala compiler know how to resolve
implicit parameters? Compiler search for an object that has the same type of an
implicit parameter and that is declared using the word
implicit. In the case of
execctx in the
object scala.concurrent.ExecutionContext.Implicits is defined the constant
During implicits resolution, the compiler search for
var/val/def that are available in the same scope of the function that as some parameters marked as
Implicit resolution is also one of the reasons why Scala compiler is so slow. In fact, implicits resolution has not any impact on runtime performances, as it is done completely at compile time. For a more detailed explanation on implicit resolution, have a look at Implicit Parameter Resolution
So far, so good. We just added another piece to our dependency injection puzzle. Now it’s time to put all the ingredients together and bake a tasty dependency injection cake.
Dependency Injection using implicits
Until now, we learned how to currying a function; We learned how implicits work in Scala. It’s time to put them all together.
As you probably already understood, we can use implicits to instruct the compiler to automatically resolve components dependencies. Let’s start from types. We have already learned that dependencies of a class should be declared in its constructor. We learned that for every parameter of a function or method that is marked as
implicit, the compiler search for an object of the same type in the appropriate scope.
In the above example, we declared a
SimpleUserService class, which declares as its unique external dependency an instance of the type
UserRepository. The dependency is marked as
implicit. To let the compiler properly resolve this dependency, we have to provide an object of type
UserRepository marked as
implicit in the same scope of the clients of the class
We have declared also a
UserService trait over the class, such that clients of this class have not to deal with the boilerplate code of implicits.
We have mainly two possibilities to provide this information to the compiler. The first is to use a configuration trait to mix with every class that declares an implicit dependency.
We chose to mix the trait into the companion object of the class to avoid replication of the instances of the variable
The second approach is to use a package object placed in the same package of the class
Using the latter approach, the definition of the object
UserController is not polluted by any external and strange extensions. The drawback is that it becomes harder to trace how each implicit parameter is resolved by the compiler.
Easy enough! We have just implemented dependency injection in Scala using implicits! Wow! But, wait: why did we introduce also function curring? We did not use currying by now.
The secret is soon unveiled. The above examples treat dependency injection in object-oriented programming. But, what about functional programming? In functional programming, there is the same requirement for functions to declare and resolve their dependencies. In this world, the only way to declare a dependency is to put it into the signature. In this way, a client of the function can provide the needed dependency at the same time of the function call.
To clearly divide the inputs of the functions and the declaration of dependencies, avoiding polluting of the signature, we can use currying.
Finally, to let the compiler to resolve automatically the dependencies, we can use implicits, as we did for the object-oriented case. This technique is called implicit parameter.
“This is the end, my only friend, the end”. We just analyzed the techniques we can use to implement natively dependency injection in Scala: Implicits. We analyzed in details the features of the language that helps us to achieve the goal: implicits and function currying. We showed an example both using object-oriented programming and functional programming. Well.
Different from the Cake Pattern, implicits gives us a mechanism to implement dependency injection that is concise and sexy.
Dependencies are resolved at compile-time, you write less code, there is no boilerplate, classes are loosely coupled, everything is extendable yet still typesafe.
On the other end, implicits resolution can become hard to understand an maintain very quickly.
It is common to use package objects with implicits, so there is no way to eyeball that this small import on top of a file feeds several functions calls with implicit variables. Even worse, it is impossible to understand from a code that this particular function call needs implicits.
As for any other technique in programming, we always have to compare pros and cons. In my opinion, if using properly, implicits offers more pros than cons. What do you think? Anybody with some bad story about implicits out of there? Cheers.
- JSR 330: Dependency Injection for Java
- Tour of Scala - Self-type
- Chapter 12: Higher-Order Functions, Section 12.8: Currying. Scala for the Impatient, Cay S. Horstmann, 2010, Addison Wesley
- Chapter 21: Implicits, Section 21.5: Implicit Parameters. Scala for the Impatient, Cay S. Horstmann, 2010, Addison Wesley
- Make Them Suffer / Scala Implicit Hell
- Implicit Parameter Resolution
- WHERE DOES SCALA LOOK FOR IMPLICITS?
- Available spec is silent on the fact that the implicit scope of a.A includes package object a