原始"nulls"和Java 8

Question

我知道处理null原语的最佳实践是使用盒装包装器,例如Integer代替int,如此处所讨论的

原始数据类型为空

但是,今天Java 8引入了可选的原语,例如OptionalInt,它OptionalInt.empty()实际上代表了一个null值吗？我的理解是Optionals只应该用于方法返回类型,而不能用作属性本身的类型."nullable"原语是否仍应存储为盒装属性？它们应该只Optional在方法返回类型中吗？或者存储OptionalInt在属性本身？

Answer 1

假设你有一个方法

public void logRequest(Integer userID, String content){
    //log content locally or in db or a rest call
}

假设您userID从特定用户获取from数据库.可以有以下几种可能性:

• DB返回一个userID.
• 找不到ID.

所以现在如果没有找到id,你会传递给logRequest什么？

• 你通过了null？如果该方法没有适当的空检查怎么办？它应该推断出null什么？
• 你应该通过0还是-1？如果null是,0那么它可能与ID为的实际用户相矛盾0.你如何区分null和0？

当然,上述问题可以通过适当的文档和修复规则来解决,但它会带来更高的维护并且容易出错.正确编写的代码应该是它自己的文档.

现在说该方法被声明为:

public void logRequest(OptionalInt userID, String content)

该方法本身非常清楚它需要一个可选的参数.因此只有2种情况需要处理:发送适当的参数(这意味着不使用旁路0).如果optional是空的,那么method正确地知道如何处理.(与之前我们不得不阅读其文档来预测行为).

所以它自己的方法声明清楚地说明了行为,而不是文档为你做,并依赖于文档和疯狂猜测.在这种情况下,可选项非常有用.

PS:我总是感觉到一种吝啬的传递null给一种期待的方法Integer.这绝对是错的!天哪,在爪哇,潜意识的头脑总是将整体视为原始人.它们并不意味着被置之不理.