java - 可选化 Java getter

Question

在 Scala 中使用 Java 时，我们必须考虑 null。

例如，HttpServletRequest getter(getAttribute、getHeader 等)都可能返回 null。

我知道我可以在每次调用 HttpServletRequest 方法时手动执行 case/match 或 map 操作，但这有点乏味。此外，像 request.getHeader("Accept-Encoding") 这样的方法调用很麻烦。

我想出了一个丰富的方法来处理这两个问题:

class Servlet_Request_Provides_NullSafe_Getters (r: HttpServletRequest) {

  def header(s: String) = Option( r.getHeader(s) )
  def attrib(s: String) = Option( r.getAttribute(s) )
  def remoteHost        = Option( r.getRemoteHost )
  def accepts = header("Accept-Encoding")
}
implicit def request2Option(r: HttpServletRequest) = 
  new Servlet_Request_Provides_NullSafe_Getters(r)

1) 有没有比 enrich-my-library 更好的方法来达到相同/相似的效果？
2)如果这是“the”方法，性能影响/风险是什么？换句话说，人们会被这种模式的明显效用/便利所困扰吗？

抱歉，如果这些东西很明显，前几天才开始充实，而且看起来确实很有用。只是想确保我在正确的场景中应用该模式...

编辑
@dhg 指出 Option.apply() 和:

def safe[T](v: T) = v match {
  case null => None
  case x => Some(x)
}

是等效的，所以 getter 方法现在使用 Option(f()) 而不是我无关的 safe(f()) 包装器

谢谢

Answer 1

正如评论中已经提到的:

def safe[T](v: T) = Option(v)

Option(v) 等同于:

v match {
  case null => None
  case x    => Some(x)
}

此外，safe 方法不必要地公开并且是类的一部分。我建议简单地内联它。

2) If this is "the" way to go, what are the performance impacts/risks?

通常调整 Java 遗留 API 以利用 Option 是个好主意。我经常使用可以返回 null 的 EntityManager.find() 执行此操作。

您的隐式转换也很好。但是不要在类名中使用下划线，Java/Scala 命名约定更喜欢 CamelCase。