6

我在 Scala 中经常看到这种类型的模式（在此处找到此示例）：

class UserActor extends Actor {
  def receive = {
    case GetUser(id) =>
      // load the user, reply with None or Some(user)
      val user: Option[User] = ... 
      sender ! user
    case FindAll() =>
      // find all users
      val users: List[User] = ...
      sender ! users
    case Save(user) =>
      // persist the user
      sender ! Right(user)
  }
}

因此，根据您获得的调用：Option[User]、List[User]、Right[User]。这个方法不错！我只是出于兴趣问这是否是最佳的？例如（这可能是一个糟糕的问题）：总是返回 List[User] 来尝试泛化是否会使 API 变得更好或更糟？因此，当未找到用户或保存失败时，列表将为空。我只是好奇......关于如何改进上述“模式”的任何其他建议？

我只是想为这种风格的 API 确定一个完美的模式，有时你会得到一个实体，有时没有，有时是它们的列表。有没有“最好”的方法来做到这一点，或者每个人都扮演自己的角色？

4

2 回答 2

15

返回类型应该有助于阐明 API 的预期行为。

如果GetUser返回 a List，开发人员可能会感到困惑，并想知道是否可能返回多个用户。当他们看到Option返回 an 时，他们会立即理解预期的行为。

我曾经不得不使用一个相当复杂的 API，它提供了以您描述的方式概括的 CRUD 操作。我发现它难以理解、定义模糊且难以使用。

于 2012-08-07T02:52:01.063 回答
1

在我看来，这是一个非常好的 API 设计模式。
如果我想返回单个元素，我经常Option将其用作函数的返回类型，显然是因为我不需要处理null. 返回 aSeq自然适用于多个元素，Either如果您想返回故障描述，这是最佳选择，我在解析 I/O 时经常使用它。有时我什至将Seq与其他之一结合起来。您可能不知道 API 用户的偏好和目标，因此提供所有这些返回类型以使用户感到尽可能舒适是有意义的。

于 2012-08-07T06:14:42.300 回答