Scala traits / cake pattern vs case classes

Question

In my web application authorized user has at least 4 "facets": http session related data, persistent data, facebook data, runtime business data.

I've decided to go with case class composition instead of traits for at least two reasons:

• traits mixing can cause name clashes
• i want the free case class goodies like pattern matching and copy method

I'd like to know experienced scalaists opinions on this subject. It looks like traits and/or cake pattern should be suitable for such tasks but as i've mentioned above there are problems... Its obvious that not only i want to implement it fast and easy but also to understand it in depth for using in future.

So does my decision have any flaws and misunderstanding or is it right? Related code looks like this:

case class FacebookUserInfo(name: String, friends: List[Long])
case class HttpUserInfo(sessionId: String, lastInteractionTime: Long, reconnect: Boolean)
case class RuntimeQuizUserInfo(recentScore: Int)
trait UserState {
  def db: User
  def http: HttpUserInfo
}

case class ConnectingUser(db: User, http: HttpUserInfo) extends UserState
case class DisconnectedUser(db: User, http: HttpUserInfo, facebook: Option[FacebookUserInfo]) extends UserState
case class AuthorizedUser(db: User, http: HttpUserInfo, facebook: FacebookUserInfo,
                          quiz: RuntimeQuizUserInfo) extends UserState

Answer 1

I think the answer is easy: Go with inheritance, as long as everything really "belongs" to your object, as long as everything is in the same "problem domain".

The intention of the cake pattern is to factor out parts of the object that are somehow required, but are not really part of it, e.g. a strategy, a decoration, a configuration, a context etc. Logging would be a typical example. Generally we're talking about situations you don't want to "hard-wire" things, e.g. cases you would consider to use a DI framework (like Guice or Spring) in Java. See http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di.html for a good example.

A question that often helps to decide what to do is: "How could I test the object behavior?". If you find it difficult to set up a proper test environment, chances are that you should decouple things, and that means DI, which can be often realized conveniently with the cake pattern.