importance of cake pattern in scala

Question

I have started learning scala for a while now and now looking at cake pattern. I got the example from here

trait UserRepositoryComponent {
  def userLocator: UserLocator

  trait UserLocator {
    def findAll: List[User]
  }
}

trait UserRepositoryJPAComponent extends UserRepositoryComponent {
  val em: EntityManager

  def userLocator = new UserLocatorJPA(em)

  class UserLocatorJPA(val em: EntityManager) extends UserLocator {
    def findAll = {
      println("Executing a JPA query")
      List(new User, new User)
    }
  }
}

trait UserServiceComponent {
  def userService: UserService

  trait UserService {
    def findAll: List[User]
  }
}

trait DefaultUserServiceComponent extends UserServiceComponent {
  this: UserRepositoryComponent =>

  def userService = new DefaultUserService

  class DefaultUserService extends UserService {
    def findAll = userLocator.findAll
  }
}

To me it looks like too many boilerplate code to get the JPA repository injected to service.

However this code would do the same with much lesser number of lines

trait UserRepository {
  def findAll
}

trait JPAUserRepository extends UserRepository {
  val em: EntityManager
  def findAll = {
    em.createQuery
    println("find using JPA")
  }
}

trait MyService {
  def findAll
}

trait MyDefaultService extends MyService {
  this: UserRepository=>
}

Instantiating both scenarios.

val t1 = new DefaultUserServiceComponent with UserRepositoryJPAComponent {
  val em = new EntityManager()
}
t1.userService.findAll


val t2 = new MyDefaultService with JPAUserRepository {
  val em = new EntityManager
}

t2.findAll

Second scenario uses much less code, and uses DI. Can you help me understand what extra advantages cake pattern brings.

Answer 1

As I understand it, there is no much difference. Actually cake pattern is IoC. It's just the idea of implementing IoC and DI, without separate DI framework, but just with scala code. You probably should prefer it over separate DI container unless you need more functionality.

Also it looks to me like both of your examples are cake patterns. At least that's how I understand it. But Martin didn't name it "cake pattern" in his book, and I base my knowledge of scala mosly on a single book, so I might be missing something. My understanding is that cake pattern is idea combining different traits to achieve DI

I think Martin specifically mentioned in his book, that it is alright to use DI-containers such as Spring in scala, but I unfortunately cannot find this place

Update

Found it: http://www.artima.com/pins1ed/modular-programming-using-objects.html See last subparagraph of 27.1 The problem. But as I said, he is not talking about "cakes" here, though the idea looks the same from the article you gave

Update 2

I've just reread my answer and understood that I need to improve it, as it does not fully answers the question.

You should prefer "cake pattern", because it is simpler. If you use Spring, you have to maintain configuration, whether it is XML or annotations, you may also have some requirements over your classes (I haven't used Spring, so I'm not sure whether there are any), and you have to bring whole Spring with you. With cake pattern you just write code as simple as it is (your second example is simple, you should agree). What's nice about scala is that you can do a lot of stuff with it, and use only a few frameworks - if you compare it to java, - you usually use many more external libraries

If you ever need more advanced functionality, like proxies - you may switch to Spring, or continue use Scala and solve your problems with the language itself, hopefully scala is extremely powerful and should cover even complicated cases.

The difference between two code pieces you provided is just abstraction: the first one has one more abstraction over operations defined in repository and service, and these are not part of the pattern. I do not feel like this is required, but author decided to show it like this.