Resolve me, Implicitly
Tags: scala, programming
Published: 2017-10-17 09:40:25

---
title: "Resolve me, Implicitly"
published: true
description: "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!"
tags: scala, programming
cover_image: https://thepracticaldev.s3.amazonaws.com/i/aqfgw1angfdi2x8qts1v.jpg
---

*Originally posted on: [Big ball of mud](http://rcardin.github.io/)*

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](http://rcardin.github.io/design/2014/08/28/eat-that-cake.html). Now it's time to talk about dependency injection through the use of implicits. Let this race starts!

## The problem: dependency injection

### Dependency
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](http://rcardin.github.io/programming/oop/software-engineering/2017/04/10/dependency-dot.html).
For sake of completeness, let's give an example of the simplest type of dependency: Association.

```scala
class A {
  // ...
}
class B(val a: A) {
  // ...
}
```

An association means that a class is *made of* references to other classes.

### Dependency injection
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.

![Resolve your declared dependencies](https://i.imgflip.com/1xlkmb.jpg)

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.

```scala
class Connection (private val mainActor: ActorSelection) {
  // Some cool stuff
}
```

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](http://rcardin.github.io/programming/software-design/java/scala/di/2016/08/01/resolve-problems-dependency-injection.html).

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.

1. Spring framework
2. Guice
3. Weld
4. Dagger 2

There is also a _Java Specification Requests_ dedicated to dependency injection, the [JSR 330](https://jcp.org/en/jsr/detail?id=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](http://rcardin.github.io/design/2014/08/28/eat-that-cake.html), which implements dependency resolution using traits and [self-type](https://docs.scala-lang.org/tour/self-types.html). This time I want to write about a dependency injection mechanisms that uses two other features of Scala, _function currying_, and _implicits_.

### Currying
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:

```scala
def mul(x: Int, y: Int) = x * y
```

We can refactor this function into a new one, that takes only one parameter and returns a new function.

```scala
def mulOneAtTime(x: Int) = (y: Int) => x * y
```

To multiply two integers you have to call the last function in the following way.

```scala
mulOneAtTime(7)(6) // Returns 42
```

We said the function `mulOneAtTime` is equal to the curried function of the original function `mul`. 

> 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:

```scala
def mulOneAtTime(x: Int)(y: Int) = x * y
```

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.

![Function currying be like](https://i.imgflip.com/1xlkul.jpg)

### Implicits
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:

```scala
object Future {
  def apply[T](body: => T)(implicit execctx: ExecutionContext): Future[T]
}

// Usage - thanks to Stanislav Spiridonov for the funny example :)
import scala.concurrent._
import scala.concurrent.ExecutionContext.Implicits.global

val beast = hell.createBeastFor(credentials)
val f: Future[Option[Blood]] = Future {
  beast.tear(user)
}
```

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 `global`.

```scala
implicit lazy val global: ExecutionContext = ???
```

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`. 

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](http://daily-scala.blogspot.it/2010/04/implicit-parameter-resolution.html)

![Implicits, implicits everywhere](https://i.imgflip.com/1xll84.jpg)

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.

#### Object-oriented programming
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.

```scala
trait UserService {
  def findById(id: String): User
}
class SimpleUserService(implict repository: UserRepository) extends UserService {
  override def findById(id: String): User = repository.findUser(id)
}
```

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 `SimpleUserService`.

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.

```scala
trait Conf {
  implicit val repository = new MongoDbUserRepository
}
object UserController extends Conf
class UserController {
  // I know, this code is not the best :P
  def findById(id: String) = new UserService().findById(id)
}
```

We chose to mix the trait into the _companion object_ of the class to avoid replication of the instances of the variable `repository`.

The second approach is to use a package object placed in the same package of the class `UserController`.

```scala
package controllers {
  class UserController {
    // I know, this code is not the best :P
    def findById(id: String) = new UserService().findById(id)
  }
}
package object controllers {
  implicit val repository = new MongoDbUserRepository
}
```

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.

![Y U not explicit the implicits!](https://i.imgflip.com/1xn1z9.jpg)

#### Functional programming
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.

```scala
// The example is taken from the book Scala for the Impatient
case class Delimiters(left: String, right: String)
def quote(what: String, delims: Delimiters) = delims.left + what + delims.right
```

To clearly divide the inputs of the functions and the declaration of dependencies, avoiding polluting of the signature, we can use currying.

```scala
def quote(what: String)(delims: Delimiters) = delims.left + what + delims.right
```

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_.

```scala
def quote(what: String)(implicit delims: Delimiters) = 
  delims.left + what + delims.right
```

## Conclusions
"_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.

## Refereces
- [JSR 330: Dependency Injection for Java](https://jcp.org/en/jsr/detail?id=330)
- [Tour of Scala - Self-type](https://docs.scala-lang.org/tour/self-types.html)
- [Chapter 12: Higher-Order Functions, Section 12.8: Currying. Scala for the Impatient, 	
Cay S. Horstmann, 2010, Addison Wesley](https://www.amazon.it/Scala-Impatient-Cay-S-Horstmann/dp/0321774094)
- [Chapter 21: Implicits, Section 21.5: Implicit Parameters. Scala for the Impatient, 	
Cay S. Horstmann, 2010, Addison Wesley](https://www.amazon.it/Scala-Impatient-Cay-S-Horstmann/dp/0321774094)
- [Currying](https://en.wikipedia.org/wiki/Currying)
- [Make Them Suffer / Scala Implicit Hell](http://spiridonov.pro/2015/10/14/scala-implicit-hell/)
- [Implicit Parameter Resolution](http://daily-scala.blogspot.it/2010/04/implicit-parameter-resolution.html)
- [WHERE DOES SCALA LOOK FOR IMPLICITS?](http://docs.scala-lang.org/tutorials/FAQ/finding-implicits.html)
- [Available spec is silent on the fact that the implicit scope of a.A includes package object a](https://issues.scala-lang.org/browse/SI-4427)