Reading my posts, you can easily find that there is a topic that I care about a lot: Dependency management in the development process. There is a feature of the Scala programming language that I've liked since the beginning. Without any external library, it is possible to successfully implement various 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's start the race!
The Problem: Dependency Injection
I have written many times about this topic, so 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 the 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 the process that a component has to take place to resolve them. Dependency 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: dependency 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 accredited by the developer 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 objects. 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 as the following.
- Spring Framework
- Dagger 2
There is also a JSR dedicated to dependency injection, 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 for any kind of external library. 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 mechanism that uses two other features of Scala, function currying and implicits.
As you know, Scala is known 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 language saves 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 some 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 the method
apply is automatically resolved and provided by the compiler to the program. How does the Scala compiler know how to resolve
implicit parameters? It searches 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, it is defined with the constant
During implicit resolution, the compiler searches for
var/val/def that are available in the same scope of the function as some parameters marked as
Implicit resolution is also one of the reasons why the Scala compiler is so slow. In fact, implicit resolution has no impact on runtime performance, as it is done completely at compile time. For a more detailed explanation of 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 curry a function and 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 component dependencies. Let’s start with 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 searches 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 so that clients of this class do not have to deal with the boilerplate code of implicits.
We have two main 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 also introduce function currying? We did not use it.
The secret is soon unveiled. The above examples consider 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 as the function call.
To clearly divide the inputs of the functions and the declaration of dependencies, avoiding polluting the signature, we can use currying.
Finally, to let the compiler to automatically resolve the dependencies, we can use implicits, as we did for the object-oriented case. This technique is called implicit parameters.
“This is the end, my only friend, the end.” We just analyzed the techniques we can use to natively implement dependency injection in Scala: implicits. We analyzed in detail the features of the language that help us to achieve our goal: implicits and function currying. We showed an example both using object-oriented programming and functional programming.
Different from the Cake Pattern, implicits give 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 hand, implicit resolution can become hard to understand and 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 function calls with implicit variables. Even worse, it is impossible to understand from 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 used properly, implicits offer 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