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 の完璧なパターンを特定しようとしています。エンティティを 1 つ取得する場合もあれば、エンティティを取得しない場合もあれば、エンティティのリストを取得する場合もあります。これを行うための「最善の」方法はありますか、それとも誰もが自分の役割を果たしますか?

4

2 に答える 2

15

リターンタイプは、APIの意図された動作を明確にするのに役立つはずです。

がGetUser返されるListと、開発者は混乱し、複数のユーザーが返される可能性があるかどうか疑問に思う可能性があります。が返されるのを見るとOption、意図した動作をすぐに理解します。

私はかつて、あなたが説明する方法で一般化されたCRUD操作を提供するかなり複雑なAPIを使用する必要がありました。理解するのが難しく、漠然と定義されており、操作するのが難しいことがわかりました。

于 2012-08-07T02:52:01.063 に答える
1

私の意見では、これはAPI設計にとって非常に良いパターンです。 単一の要素を返したい場合は、関数の戻り型として
頻繁に使用します。これは、明らかに、を処理する必要がないためです。aを返すことは当然複数の要素に対してであり、失敗の説明を返したい場合に最適です。私はI/Oを解析するときによく使用します。時々私は他の1つと組み合わせることさえあります。APIのユーザーの好みや目標がわからない可能性が高いため、ユーザーができるだけ快適に感じるように、これらのリターンタイプをすべて提供することが重要です。OptionnullSeqEitherSeq

于 2012-08-07T06:14:42.300 に答える