Rule 3.1 example?

[iamthiago]

Would be nice to demonstrate a best practice instead of a cake pattern implementation.

[jawshooah]

I'd appreciate this as well. I have yet to come across a better pure-scala solution for dependency injection and modularity. I'm vaguely familiar with the reader monad pattern, but that seems a stretch too far for general use, when many devs are likely unfamiliar with the intricacies of FP.

[iamthiago]

Is that a good example to replace the cake pattern?
http://di-in-scala.github.io/

[alexandru]

@thiagoandrade6, @jawshooah, the alternative to the Cake Pattern is plain old constructor arguments.

Why would you do something like this:

trait SomeServiceComponent {
  val someService: SomeService // abstract
  trait SomeService { ??? }
}

trait SomeServiceComponentImpl extends SomeServiceComponent {
  self: DBServiceComponent =>

  val someService = new SomeServiceImpl
  class SomeServiceImpl extends SomeService { ??? }
}

When this is much more readable and common sense:

class SomeService(db: DBService) { ??? }

Oh, are your dependencies going crazy? Are those constructors starting to hurt? That's a feature IMHO. I call it "pain driven development" (PDD for short). It's a sign that the architecture has started to suck and the various dependency injection techniques (such as libraries, or the Cake pattern) are not fixing the problem, but the symptoms. I wrote an article about it. It's fairly controversial, which is how I like it :-) ... https://www.bionicspirit.com/blog/2015/12/15/avoid-javaisms-code-smell.html

Anyway, the bottom line is that the answer to "Why not Cake, specifically?" is because I've never seen a codebase that uses the Cake pattern and that doesn't suck. For example by looking at that sample above you should have immediately realized that those components are probably missing lifecycle management. I would say YMMV, but I won't because I want to be proven wrong.