Scala 特征/蛋糕模式与案例类

Question

在我的 Web 应用程序中，授权用户至少有 4 个“方面”:http session 相关数据、持久数据、facebook 数据、运行时业务数据。

我决定使用案例类组合而不是特征至少有两个原因:

• 性状混合会导致名字冲突
• 我想要模式匹配和复制方法等免费案例类好东西

我想知道经验丰富的 scalaists 对这个问题的看法。看起来 traits 和/或 cake pattern 应该适合这样的任务，但正如我上面提到的那样，存在问题......很明显，我不仅想快速轻松地实现它，而且还想深入理解它以便使用 future 。

那么我的决定到底有没有瑕疵和误解，还是正确的呢？相关代码如下所示:

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

我认为答案很简单:选择继承，只要一切都真正“属于”您的对象，只要一切都在同一个“问题域”中。

蛋糕模式的目的是分解出对象的某些部分，这些部分在某种程度上是必需的，但实际上并不是它的一部分，例如策略、装饰、配置、上下文等。日志记录就是一个典型的例子。一般来说，我们谈论的是您不想“硬接线”的情况，例如您会考虑在 Java 中使用 DI 框架(如 Guice 或 Spring)的情况。参见 http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di.html一个很好的例子。

通常有助于决定做什么的一个问题是:“我如何测试对象的行为？”。如果你发现搭建一个合适的测试环境有困难，那么很可能你应该解耦，这就是DI，这通常可以用蛋糕模式很方便地实现。