Dependency Injection is part of the SOLID design principles (specifically the D: Dependency Inversion Principle).

To understand the concept behind DI, Dr. Wikipedia provides a great article (skip to the sidebar entitled Dependency injection for five-year-olds)

There are many, well-documented arguments out there regarding why to use Dependency Injection. For me, one of the best reasons is for unit testing. The ability to stub out dependencies and focus on single functional modules of code is enough for me to buy in.

While using a popular Scala DI library called Scaldi I came across a specific need: there was one service that needed to be “newed up” every time it was injected. The more common pattern in DI is that there is one “instance” of a object instantiated for the entire application, and that instance is provided to anyone who asks for it.

For my use case, the service had a piece of internal state that needed to be unique for each caller of the service. So, each caller needed its own copy of the service.

Scaldi handles this nicely with its binding overrides which are used inside the Injector provider:

bind [Server] to new HttpServer

While this may look like it is creating a new instance for each binding, it is actually not. It creates a single instance and then reuses it. To get a new instance for each binding, follow this pattern, using the toProvider key word:

bind [UserService] toProvider new UserService

The to keyword provides lazy binding, and toNonLazy is also available.