java中optionnull_Java中一致的Null值处理

null值的处理通常被认为是Java的薄弱环节，原因有很多。

最常提及的问题是著名的问题NullPointerException，尽管没有明确的理由说明为什么这是一个问题。毕竟，这只是问题的征兆，而不是问题本身。

实际问题更深。那些具有使用C或C ++编写代码的经验的人都非常了解此问题。在使用C / C ++进行编码时，工程师应始终牢记与访问安全，未定义行为，内存分配，对象复制/移动等有关的无数细微差别。所有这些众多的细节会产生持续的“压力”，消耗宝贵的工程师大脑资源，并导致开发速度降低。即使是核心的C / C ++支持者也不能否认这一事实。

nullJava中的值也存在类似的问题。

Java通常被认为是一种冗长的语言。确实如此。这是其明确性的缺点。Java中几乎所有的意图都可以(通常是)用代码显式表达。通过添加一些额外的文本，我们又获得了可立即访问的上下文，在阅读Java代码时不需要将其携带在头部。这些null值违反了此规则。他们不会在代码中显示自己。

这些null值可能由于各种原因而出现。它可以是默认初始化，从某些方法返回的值，甚至是显式分配的null值。请记住，有时null可能会出现，请检查方法文档或代码中是否有返回此类值的可能-所有这些都会产生与上述C / C ++非常相似的“压力”。

如何解决这个问题？我们如何消除影响生产率的恒定“压力”？

当然，有多种解决方法。

我们可以：

· 添加@NotNull(或类似)注释。除了添加一些(假)感觉null值以某种方式处理之外，基本上什么都不会做。

· 建立严格的规则并检查可能存在的每个值null。这是一个可行的解决方案，但是以无数null检查污染代码为代价。而且，没有人是完美的。我们可能会犯错误，编译器将无济于事。

· 发明自己的语言。Kotlin的作者就是这样做的。再次，这是一个可行的解决方案，但对我来说太过分了。然而，它有一件重要的事情：可空和不可空类型是不同的，并且在代码中清楚地表示出来。

· 使用函数式编程方法Maybe-monad的某种形式。

最后一点是我将要详细讨论的内容。

Optional： 黄金三镖客

在Java 8中引入的 Optional类旨在处理缺失值，而不是null。在某种程度上，它是Maybemonad 的Java实现(但不完全，请参见下文)。

尽管有些人认为这只是一种与null价值观打交道的好方法，但实际上它具有更为重要的好处：明确表达意图。将字段，参数或变量包装到中后Optional，您立即将意图明确并向读者清楚。换句话说，您正在添加缺少的上下文。同时，编译器开始出现差异，因此您不再孤单。

因此，Optional工程师使用，用一块石头杀死了三只鸟：

· 使潜在的缺失值在代码中明确显示，并消除阅读器的“压力”。

· 使编译器可以控制对值的访问。

· 使null值的处理变得方便。

不幸的是， Optional有它自己的问题。

如上所述，Optional“一定程度上”执行Maybemonad。它崇尚命令式世界，并具有外部可访问的价值。通过调用该 get()方法，您可以尝试检索它。但是，如果这样做，它可能会抛出NullPointerException，这违背了整个目的Optional—是潜在(即缺失)值的安全容器null。

也许这就是为什么一些聪明的头脑建议“使用Optional字段和参数是不正确的做法”的原因，而静态分析工具会针对此类用法显示警告Optional。

解决方案可能是编写您自己的版本Maybe并使用它。周围有几种不同的实现。我正在使用我的Reactive Toolbox Core库中的一个库。

摘要

在Optional/ Option/ Maybe使Java工程师使用以下约定：

· 每个具有普通类型的变量/字段/参数都不为null，也不能为null。

· 每个类型包装在Optional/ Option/中的变量/字段/参数都Maybe可能为空。

· 如果某些外部库/调用可以返回null值，则结果应立即包装在Optional/ Option/中Maybe。

无需任何额外的努力，严格遵循上述约定即可编写Java代码，该代码包括：

· 永不抛出NullPointerException并且null正确处理了所有值。

· 清楚明确地区分代码中的可为空和不可为空的值，并使编译器在编译时强制执行此区分。

最后，开发这么多年我也总结了一套学习Java的资料与面试题，如果你在技术上面想提升自己的话，可以关注我，私信发送领取资料或者在评论区留下自己的联系方式，有时间记得帮我点下转发让跟多的人看到哦。