Cake Pattern: The Bakery from the Black Lagoon
Why Stack Overflow recommends it
Stack Overflow users link it as the go-to explanation of the Cake Pattern when answering questions about traits, modularity, dependency injection and initialization order in Scala.
Recommended by 4 people across 4 different months, 2012 to 2014.
What it is
A 49-minute keynote from the 2013 Northeast Scala Symposium in which Daniel Spiewak gives a thorough walkthrough of Scala's Cake Pattern. He covers the type theory behind it, modules, common pitfalls and best practices, and argues it is useful well beyond dependency injection.
What people said
Recommends Andreas Neumann · 2013-03 · Stack Overflow · on “Is ordered initialization a requirement for dependency injection generalizations/frameworks?”
In his talk 'The Bakery from the BLACK LAGOON' Daniel Spiewak shows some ways to deal with that particular problem. Slides -> [LINK] Video -> [this video] Taken from the talk: You can get around the null-Pointer exceptions by using lazy val or def instead of val, at the price of possible deadlocks.
Recommends Daniel Mahler · 2013-05 · Stack Overflow · on “Scala project organization”
The answer partly depends on what is most important to you. If you are really serious about the quick prototype part, then as far as the physical file/directory layout, I would just start with one flat file and only start breaking it up when there is enough code to make that awkward. This should at least make global restructuring of your code easier until you get the overall structure right. Scala does not enforce the package:directory, class:file correspondence, and given the conciseness of Scala that can be overkill in many cases anyway. There is nothing to stop you organizing things into multiple packages within the one file before you break it up physically once you have the structure ri
Recommends Daniel C. Sobral · 2013-07 · Stack Overflow · on “Does trait in Scala eliminate the need of adding behaviour through dependency injection?”
Why, yes. It is known as the "cake pattern", and it can handle things much more complex than you might think. In fact, it supports modularity at a level found in very few other languages. There are plenty of information about it on the web, but I suggest the excellent presentation by Daniel Spiewak and NEScala 2013, Cake Pattern Bakery from The Black Lagoon [this video] , as a starting point.
Recommends fotNelton · 2014-01 · Stack Overflow · on “Abstracting the Database client in the cake pattern”
Daniel Spiewak [this video] shows a nice way to use traits for initialization and shutdown in this talk [this video] . As far as the abstraction of the clients is concerned, I suppose you are working with entities like users, services, etc.? These should be relatively easy to abstract over, independent of DB or Lucene. Could you provide an example? I'm afraid I still didn't get what you need exactly (no offense intended).
Cites agilesteel · 2012-07 · Stack Overflow · on “Traits vs. Packages in Scala”
After watching Martin's keynote on Reflection and Compilers [LINK] I can't seem to get this crazy question out of my head. Martin talks among other things about the "(Wedding) Cake Pattern", where traits play the central part. I'm wondering, why in the world do we need packages when we already have traits? Is there anything a package can do, what a trait (at least theoretically) cannot? I'm not talking about the current implementation, I'm just trying to imagine what programming would be like if we replace packages with traits. In my head it would be like this: one keyword less ( package is unneeded) no need for package object s To summarize all my questions: Is it theoretically possible to
Cites Marius Danila · 2013-06 · Stack Overflow · on “Type-parametrized type hierarchies”
This approach would work but you may encounter problems when the number of type parameters increases. Perhaps a solution would be to use abstract type members instead of type parameters. Another approach is to use the cake pattern which I think provides a better solution in your case. The exact logic of your code eludes me a bit, so this rewrite may not entirely represent your intention: package foolib.generic //defines common types used by all modules trait CoreModule { type Id // abstract type, not commited to any particular implementation } //module defining the EntityModule trait trait EntityModule { this: CoreModule => //specifying core module as a dependency trait GenEntity { def id: I