Scala Cake Pattern Encourage Hardcoded Dependencies?

Question

I'm still trying to learn Scala's Cake Pattern. It seems to me that it gives you the advantage of centralizing your configuration of "Components" as well as the ability to provide default implementations for those components (which are of course overridable).

However, it's use of self-type traits to describe dependencies seems to mix area-of-concerns. The purpose of the Component (I think) is to abstract away the different implementations for that component. But the dependency-listing described in the Component is itself an implementation concern.

For instance, let's say I have a database full of widgets, a registry that allows me to look up specific kinds of widgets, and some sort of algorithm that uses the registry to process the widgets:

case class Widget(id: Int, name:String)

trait DatabaseComponent {
  def database: (Int => Widget) = new DefaultDatabase()

  class DefaultDatabase extends (Int => Widget) {
    // silly impl
    def apply(x: Int) = new Person(x, "Bob")
  }
}

trait RegistryComponent {
  this: DatabaseComponent =>  // registry depends on the database

  def registry: (List[Int] => List[Widget]) = new DefaultRegistry()

  class DefaultRegistry extends (List[Int] => List[Widget]) {
    def apply(xs: List[Int]) = xs.map(database(_))
  }
}

trait AlgorithmComponent {
  this: RegistryComponent =>  // algorithm depends on the registry

  def algorithm: (() => List[Widget]) = new DefaultAlgorithm()

  class DefaultAlgorithm extends (() => List[Widget]) {
    // look up employee id's somehow, then feed them
    // to the registry for lookup
    def apply: List[Widget] = registry(List(1,2,3))
  }
}

And now you can put it together in some central config:

object Main {
  def main(args: Array[String]) {
    val algorithm = new AlgorithmComponent() with RegistryComponent with DatabaseComponent

    val widgets = println("results: " + algorithm.processor().mkString(", "))
  }
}

If I want to change to a different database, I can inject it easily by changing my mixin:

val algorithm = new AlgorithmComponent() with RegistryComponent with SomeOtherDatabaseComponent

But...what if I want to mix in a different Registry component that doesn't use a database?

If I try to subclass the RegistryComponent with a different (non-Default) implementation, the RegistryComponent will insist that I include a DatabaseComponent dependency. And I have to use RegistryComponent, because that's what the top-level AlgorithmComponent requires.

Am I missing something? The moment I use a self-type in any of my Components, I'm declaring that all possible implementations must use those same dependencies.

Has anyone else run into this issue? What is the Cake-like way of solving it?

Thanks!

Hawking

Like Dave says, you are missing interfaces, to decouple the impls. If you are looking for what the cake pattern is missing, then look at EJB and Spring: a container that is aware of concerns such as transactions, security and resource configuration. The cake pattern doesn't address that, and as such, like Google Guice, is only light weight. – Sharyl

Answer 1

With the cake pattern, at least by the example I always go to, you should separate the component's interface definition from its default implementation. This cleanly separates the interface's dependencies from the implementation's dependencies.

trait RegistryComponent {
  // no dependencies
  def registry: (List[Int] => List[Widget])
}

trait DefaultRegistryComponent extends RegistryComponent {
  this: DatabaseComponent =>  // default registry depends on the database

  def registry: (List[Int] => List[Widget]) = new DefaultRegistry()

  class DefaultRegistry extends (List[Int] => List[Widget]) {
    def apply(xs: List[Int]) = xs.map(database(_))
  }
}

Hinterland

Right. Self-types are just like any other sort of dependency declaration. They can show a dependency on a concrete entity (bad) or an abstract one (good). The only trick is that the cake pattern encodes both abstract interfaces and concrete components as traits, which can be confusing. – Tamarisk