何时使用选项/无返回类型(When to use Option/None return types)

何时使用选项/无返回类型(When to use Option/None return types)

我理解Some / None / Option背后的全部原理和概念，我当然可以赞赏它的优点。 我的问题更多的是最佳实践。 什么时候它变得过度杀伤，什么时候它宗教地使用它是有道理的。 我认为（并且我可能是错的），但尽可能多地使用它是有意义的，因为它是一种更安全的方式来传递任何东西（而不是空）。 我看到自己做了很多事情，但是有一些功能遍布地图，getOrElse，获取，匹配，甚至有时嵌套它们，看起来很丑。 是否有一些我缺少的概念，或者一些最佳做法是使用接收多个可选值的函数。 例如：

def updateJobs(id: Int) = withAuth { request => { User.userWithToken(request.headers.get("token").get).map { user => Job.jobsAfterIdForForeman(id.toString, user.id.toString) match { case Some(json) => Ok(json) case _ => NoContent } }.getOrElse(BadRequest) } }

或者更糟，例如：

def addPurchaseRequest(json: JsValue) = { (json \ "jobId").asOpt[Long].map { jobId => JobDAO.jobWithId(jobId).map { job => PurchaseRequestDAO.insert(new PurchaseRequest(json, job)).map { model => val request = model.asInstanceOf[PurchaseRequest] (json \ "items").asOpt[List[JsObject]].map { list => { if (PurchaseItemAssociationDAO.bulkInsert(PurchaseItemAssociation.itemsFromJsonArray(list, request.id))) Option(request.addResponseJson) else None } }.getOrElse(None) }.getOrElse(None) }.getOrElse(None) }.getOrElse(None) }

我设法重构一些看起来不那么疯狂，但有没有更好的方式来重构这个，所以它看起来不那么疯狂？ 我是否错过了某些东西，或者你是否习惯了看起来像这样的东西？ 似乎应该有一个更清洁的做法。

I understand the whole principle and concept behind the Some/None/Option and I can certainly appreciate its merits. My question is more of best practice. When does it become overkill and when does it make sense to use it religiously. I think (and i could be wrong) but it makes sense to use it as much as possible since it's a safer way to pass around nothing (as opposed to null). The thing I see myself doing a lot though is having some functions littered with map, getOrElse, get, match and even sometimes nesting them which tends to look ugly. Is there some concept I'm missing or some best practice to do with a function that receives multiple Optional values. For example:

def updateJobs(id: Int) = withAuth { request => { User.userWithToken(request.headers.get("token").get).map { user => Job.jobsAfterIdForForeman(id.toString, user.id.toString) match { case Some(json) => Ok(json) case _ => NoContent } }.getOrElse(BadRequest) } }

or even worse for example:

def addPurchaseRequest(json: JsValue) = { (json \ "jobId").asOpt[Long].map { jobId => JobDAO.jobWithId(jobId).map { job => PurchaseRequestDAO.insert(new PurchaseRequest(json, job)).map { model => val request = model.asInstanceOf[PurchaseRequest] (json \ "items").asOpt[List[JsObject]].map { list => { if (PurchaseItemAssociationDAO.bulkInsert(PurchaseItemAssociation.itemsFromJsonArray(list, request.id))) Option(request.addResponseJson) else None } }.getOrElse(None) }.getOrElse(None) }.getOrElse(None) }.getOrElse(None) }

I managed to refactor some to not look so crazy, but is there a better way to refactor this so it doesn't look so crazy? Am I missing something or do you get used to things just looking like this? Seems like there should certainly be a cleaner practice.

最满意答案

由于Option类是monadic，因此应该使用理解来使代码看起来更清晰。 例如，您的第二个示例可以重写为：

def addPurchaseRequest(json: JsValue) = for { jobId <- (json \ "jobId").asOpt[Long] job <- JobDAO.jobWithId(jobId) model <- PurchaseRequestDAO.insert(new PurchaseRequest(json, job)) request = model.asInstanceOf[PurchaseRequest] list <- (json \ "items").asOpt[List[JsObject]] if PurchaseItemAssociationDAO.bulkInsert(PurchaseItemAssociation.itemsFromJsonArray(list, request.id)) } yield request.addResponseJson

Since the Option class is monadic, you should use for comprehensions to make that code look cleaner. For example, your second example can be rewritten as:

def addPurchaseRequest(json: JsValue) = for { jobId <- (json \ "jobId").asOpt[Long] job <- JobDAO.jobWithId(jobId) model <- PurchaseRequestDAO.insert(new PurchaseRequest(json, job)) request = model.asInstanceOf[PurchaseRequest] list <- (json \ "items").asOpt[List[JsObject]] if PurchaseItemAssociationDAO.bulkInsert(PurchaseItemAssociation.itemsFromJsonArray(list, request.id)) } yield request.addResponseJson