这是设计Scala API的良好返回类型模式吗？

Question

我在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)
  }
}

因此,取决于您获得的呼叫:选项[用户],列表[用户],右[用户].这种方法很好!如果这是最佳的,我只是想问一下它的兴趣？例如(这可能是一个糟糕的):通过总是返回List [User]来尝试和推广它会使API变得更好或更糟吗？因此,当找不到用户或保存失败时,列表将只是空的.我只是好奇......关于如何改进上述'模式'的任何其他建议？

我只是想为这种风格的API确定一个完美的模式,你有时会得到一个实体,有时却没有,有时也只有一个列表.是否有"最佳"方式来实现这一目标,还是每个人都有自己的角色？

Answer 1

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

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

我曾经不得不使用一个相当复杂的API,它提供了以你描述的方式推广的CRUD操作.我发现它很难理解,模糊定义,难以使用.