Resolve me, Implicitly

Originally posted on: Big ball of mud

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

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.
For sake of completeness, let's give an example of the simplest type of dependency: Association.

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.

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.

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.

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

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:

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.

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

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

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:

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.

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:

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.

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

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.

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.

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.

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.

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.

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

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.

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
• 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
• Currying
• 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