這是一個很好的設計Scala API的返回類型模式嗎？

我在Scala中看到這種類型的模式（found this example here）的經常：這是一個很好的設計Scala API的返回類型模式嗎？

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

所以根據你的電話：選項[用戶]，列表[用戶]，右[用戶]。這種方法很好！如果這是最理想的，我只是在問興趣？例如（這可能是一個糟糕的）：它會使API的更好還是更糟，試圖通過總是返回List [User]來推廣？所以當用戶沒有找到或者如果保存失敗，那麼列表將只是空的。我只是好奇....關於如何改善上述「模式」的任何其他建議？

我只是試圖找出這種API風格的完美模式，你有時會得到一個實體，有時沒有，有時它們是一個列表。是否有「最好」的方式來做到這一點，或每個人都有自己的角色？

來源

2012-08-07 Jack

列表可以爲空..如果限制爲[0,1]，列表爲[0，n]，則選項很好.. – 2012-08-07 01:16:04

返回類型應該有助於闡明API的預期行爲。

如果GetUser返回List，開發人員可能會感到困惑，並懷疑是否可能返回多個用戶。當他們看到返回的Option時，他們會立即理解預期的行爲。

我曾經不得不使用一個相當複雜的API，它提供了以您描述的方式推廣的CRUD操作。我發現它很難理解，含糊不清，很難合作。

來源

2012-08-07 02:52:01 dbyrne

+1爲了引起注意，API返回類型（以及它們的參數，名稱，默認值等）扮演着某種形式文檔的重要角色。返回類型有時會被排除在外，但在答案中恰當地描述這是一個錯誤。 – 2012-08-07 06:29:36

在我看來，這是一個很好的API設計模式。
我經常使用Option作爲我函數的返回類型，如果我想返回單個元素，顯然是因爲我不需要處理null。返回一個Seq當然是多個元素，如果你想返回一個失敗描述，Either是最優的，我經常在解析I/O時使用它。有時我甚至會將Seq與其他人之一結合在一起。您可能不知道API用戶的偏好和目標，因此可以提供所有這些返回類型，以使用戶感覺儘可能舒適。

來源

2012-08-07 06:14:42

這是一個很好的設計Scala API的返回類型模式嗎？

回答

相關問題