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

Question

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

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

• 特征混合可能会导致名称冲突
• 我想要免费的案例类好东西，例如模式匹配和复制方法

我想知道经验丰富的 scalaists 对这个主题的看法。看起来特质和/或蛋糕模式应该适合这样的任务，但正如我上面提到的，存在问题......很明显，我不仅想快速、简单地实现它，而且还想深入理解它以便使用未来。

那么我的决定到底有没有缺陷和误解，还是正确的呢？ 相关代码如下：

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，这通常可以通过蛋糕模式方便地实现。

Answer 2

第三个选项是使用隐式转换器，又名“pimp my library”这可能不是必需的，因为您可以控制代码。

这完全取决于您希望对象的某些方面的不透明（或透明）程度。您可以向世界其他地方假装它是一个普通的旧案例类，但在内部通过使用隐式使其完成额外的工作。使用 case 类来保存数据是合适的，但我也觉得使用三个类（ConnectingUser、DisconnectedUser、AuthenticatedUser 来表示同一个对象很尴尬） code>) 取决于她的身份验证状态。

对于 UserState，您可以提供一个提取器，使其行为类似于案例类：

object UserState {
  def unapply(state: UserState) = Some(state.db, state.http)
}

这可以在匹配状态中使用，如下所示：

val user = ConnectingUser(User(), HttpUserInfo("foo", 0, false))
user match {
  case UserState(db, http) => println(http)
}