可选项化的Java getter

从Scala使用Java时,我们必须考虑null.

例如,HttpServletRequest的getter(getAttribute,getHeader等)都可能返回null.

我知道我可以在每次调用HttpServletRequest方法时手动执行大小写/匹配或映射操作,但这有点乏味.同样,诸如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)除了丰富我的图书馆,还有其他/更好的方法来实现相同/相似的影响吗？
2)如果这是“可行的”方法,那么性能影响/风险是什么？换句话说,这种模式的表面上的实用性/便利性会烧死人吗？

很抱歉,如果这些东西很明显,只是在第二天才开始充实,这确实很有用.只是要确保我在适当的情况下应用该模式…

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

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

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

谢谢

解决方法:

正如评论中已经提到的：

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

选项(v)等效于：

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

同样,安全方法不必要地公开了,并且是该类的一部分.我建议简单地对其进行内联.

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

通常,使Java旧版API适应使用Option是一个好主意.我经常使用EntityManager.find()来返回空值.

您的隐式转换也可以.但是,不要在类名中使用下划线,Java / Scala命名约定更喜欢CamelCase.

可选项化的Java getter

相关文章