I am the founder and lead developer of Hibernate Envers, a Hibernate core module, which provides entity versioning/auditing capabilities. I am also one of the co-founders of SoftwareMill, a company specializing in delivering customized software solutions (http://softwaremill.com, "Extraordinary software as a standard"), based on Java and JBoss technologies. After work, apart from being involved in development of Envers, I work on several small open source projects, like ElasticMQ (simple message queue written in Scala with an SQS interface), projects around static analysis (using JSR 308 - Typestate Annotations/ Checkers Framework and FindBugs), and some CDI/Weld (not always portable) extensions, like autofactories or stackable security interceptors. I am also interested in new JVM-based languages, especially with functional elements (like Scala, JRuby) and frameworks built using them (like Lift), as well as improving the ways we use Dependency Injection. Adam is a DZone MVB and is not an employee of DZone and has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Dependency Injection in Scala: Extending the Cake Pattern

01.14.2011
| 7017 views |
  • submit to reddit

Continuing the mini-series on Dependency Injection (see my previous blogs: problems with DI, assisted inject for CDI and improving assisted inject), I took a look at how DI is handled in Scala.

There are several approaches, one of the most interesting being the Cake Pattern. It is a DI solution that uses only native language features, without any framework support. For a good introduction see either Jonas Boner’s blog (on which this post is largerly based) or Martin Odersky’s paper Scalable Component Abstractions.

I would like to extend the Cake Pattern to allow defining dependencies which need some user-provided data to be constructed (like in autofactories/assisted inject).

The Cake Pattern: interfaces

But let’s start with an example of the base pattern. Let’s say that we have a User class,

sealed case class User(username: String)

and that we want to create a UserRepository service. Using the Cake Pattern, first we create the “interface”:

trait UserRepositoryComponent { // For expressing dependencies
def userRepository: UserRepository // Way to obtain the dependency

trait UserRepository { // Interface exposed to the user
def find(username: String): User
}
}

We have three important things here:

  • the UserRepositoryComponent trait will be used to express dependencies. It contains the component definition, consiting of:
  • a way to obtain the dependency: the def userRepository method (could also be a val, but why a def is better I’ll explain later)
  • the interface itself, here a UserRepository trait, which gives the functionality of locating users by username

The Cake Pattern: implementations

An implementation of a component looks pretty similar:

trait UserRepositoryComponentHibernateImpl
extends UserRepositoryComponent {
def userRepository = new UserRepositoryImpl

class UserRepositoryImpl extends UserRepository {
def find(username: String): User = {
println("Find with Hibernate: " + username)
new User(username)
}
}
}

Nothing special here. The component implementation extends the “interface” component trait. This brings into scope the UserRepository trait, which can be implemented.

Using dependencies

How can one component/service say that it depends on another? Scala’s self-type annotations are of much use here. For example, if a UserAuthorization component requires the UserRepository, we can write this as follows:

// Component definition, as before
trait UserAuthorizationComponent {
def userAuthorization: UserAuthorization

trait UserAuthorization {
def authorize(user: User)
}
}

// Component implementation
trait UserAuthorizationComponentImpl
extends UserAuthorizationComponent {
// Dependencies
this: UserRepositoryComponent =>

def userAuthorization = new UserAuthorizationImpl

class UserAuthorizationImpl extends UserAuthorization {
def authorize(user: User) {
println("Authorizing " + user.username)
// Obtaining the dependency and calling a method on it
userRepository.find(user.username)
}
}
}

The important part here is this: UserRepositoryComponent =>. By this code fragment we specify that the UserAuthorizationComponentImpl requires some implementation of the UserRepositoryComponent. This also brings the content of the UserRepositoryComponent into scope, so both the method to obtain the user repository and the UserRepository trait itself are visible.

Wiring

How do we wire different components together? Again quite easily. For example:

val env = new UserAuthorizationComponentImpl
with UserRepositoryComponentHibernateImpl

env.userAuthorization.authorize(User("1"))

First we need to construct the environment, by combining all of the components implementations that we want to use into a single object. Next, we can call methods on the environment to obtain services.

What about testing? Also easy:

val envTesting = new UserAuthorizationComponentImpl
with UserRepositoryComponent {
def userRepository = mock(classOf[UserRepository])
}
envTesting.userAuthorization.authorize(User("3"))

Here we have mocked the user repository, so we can test the UserAuthorizationComponentImpl in isolation.

defs over vals

Why are defs in the component definition better as the way to obtain the dependency? Because if you use a val, all implementations are locked and have to provide a single dependency instance (a constant). With a method, you can return different values on each invocation. For example, in a web environment, this is a great way to implement scoping! The method can read from the request or session state. Of course, it is still possible to provide a singleton. Or a new instance of the dependency on each invocation.

Dependencies that need user data

Finally, we arrive to the main point. What if our dependencies need some data at runtime? For example, if we wanted to create a UserInformation service, which wraps a User instance?

Well, who said the the methods by which we obtain the dependencies need to be parameterless?

// Interface
trait UserInformationComponent {
// What is needed to create the component
def userInformation(user: User)

trait UserInformation {
def userCountry: Country
}
}

// Implementation
trait UserInformationComponentImpl
extends UserInformationComponent {
// Dependencies
this: CountryRepositoryComponent =>

def userInformation(user: User) = new UserInformationImpl(user)

class UserInformationImpl(val user: User) extends UserInformation {
def userCountry: Country {
// Using the dependency
countryRepository.findByEmail(user.email)
}
}
}

// Usage
val env = new UserInformationComponentImpl
with CountryRepositoryComponentImpl
env.userInformation(User("someuser@domain.pl")).userCountry

Isn’t this better than passing the User instance as a method parameter?

Using the Cake Pattern, creating stateful dependencies, which can be created at run-time with user-provided data, and still depend on other components is a breeze. This is similar to a factory method, however with much less noise.

The good and the bad

The good:

  • no framework required, using only language features
  • type safe – a missing dependency is found at compile-time
  • powerful – “assisted inject”, scoping possible by implementing the dependency-providing method appropriately

The bad:

  • quite a lot of boilerplate code: each component has a component interface, implementation, service interface and service implementation

However, I don’t think defining all four parts is always necessary. If there’s only one implementation of a component, you can combine the component interface and implementation into one, and if there’s a need, refactor later.

Adam

From http://www.warski.org/blog/?p=291

Published at DZone with permission of Adam Warski, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Liam Knox replied on Fri, 2011/01/14 - 10:56pm

Is it just me but is this the most complex thing ever invented when compared to Spring IoC? I think I will stick to Java and a splash of Spring

Esko Luontola replied on Sun, 2011/01/16 - 4:15pm

I will stick with just having constructor parameters. It doesn't require any framework, it's type safe, and most of all it's simple.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.