处理空值值通常被认为是Java中的弱点。 有几个原因。
最常提及的问题是著名的空指针异常，尽管没有明确的理由说明这是一个问题。 毕竟，这只是问题的征兆，而不是问题本身。
实际问题更深。 那些有使用C或C ++编写代码的经验的人对此问题了解得更好。 使用C / C ++进行编程时，工程师应始终牢记与访问安全，未定义行为，内存分配，对象复制/移动等有关的无数细微差别。 所有这些繁琐的细节造成了持续的“压力”，消耗了宝贵的工程师大脑资源，并导致开发速度降低。 即使是核心的C / C ++支持者也不能否认这一事实。
存在类似的问题空值Java中的值。
Java通常被认为是冗长的语言。 确实如此。 这是其明确性的背面。 Java中几乎所有的意图都可以（通常是）用代码显式表达。 通过添加一些额外的文本，我们又获得了可立即访问的上下文，在阅读Java代码时无需将其携带在头。 的空值价值观违反了这一规则。 他们不会在代码中显示自己。
的空值值可能由于各种原因而出现。 它可以是默认的初始化，从某些方法返回的值，甚至可以是明确分配的值空值值。 请记住，有时空值可能会出现，检查方法文档或代码中是否可能返回该值-所有这些都会产生与上述C / C ++非常相似的“压力”。
如何解决这个问题？ 如何消除影响我们生产率的恒定“压力”？
当然，有多种解决方法。 我们可以：
- 加@NotNull（或类似）注释。 除了添加一些（假）的感觉，基本上什么也没有空值值以某种方式处理。建立严格的规则并检查可能存在的每个值空值。 它是有效的解决方案，但以无数污染代码为代价空值检查。 而且，好吧，没有人是完美的，我们会犯错误，而编译器将无济于事。Invent own language. Authors of Kotlin done just that. Again, this is working solution, but it's overkill, as for me. Nevertheless it has one important thing: 空值able and non-空值able types are distinct and clearly expressed in the code.使用函数式编程方法-也许monad以某种形式存在。
最后一点是我将要详细讨论的内容。
Optional: good, bad, ugly
在Java 8中引入可选的类旨在处理缺失值，而不是空值。 在某种程度上，它是Java的实现也许monad（但不完全，请参见下文）。
尽管有些人可以将其视为一种理想的工作方式空值值，它实际上具有更重要的好处：意图的明确表达。 将字段，参数或变量包装到可选的您立即向读者表明了自己的意图。 换句话说-您要添加缺少的上下文。 在编译器开始看到差异的同时，您不再孤单。
因此，通过使用可选的工程师用一块石头杀死了三只鸟：
- 使潜在的缺失值在代码中明确显示，并消除阅读器的“压力”。使编译器可以控制对值的访问。使处理空值值方便。
不幸可选的有自己的问题。
正如刚才提到的，可选的“一定程度上”的执行也许单子。 它崇尚命令式世界，并具有外部可访问的价值。 通过致电得到（）您可以尝试检索它的方法。 但是，如果这样做，它可能会抛出空指针异常。 这违背了可选的-是安全潜力的容器空值（即丢失）值。
也许这就是为什么一些聪明的头脑建议“使用可选的对于字段和参数，则是不正确的做法”，静态分析工具会针对此类用法显示警告可选的。
The solution might be to write your own version of Maybe and use it instead. There are several different implementations around. I'm using one from my Reactive Ťoolbox Core library.
Summary
的可选的/选项/也许使Java工程师可以使用以下约定：
- 每个具有普通类型的变量/字段/参数都不为空值，也不能为空值。包装类型的每个变量/字段/参数可选的/选项/也许-可能为空。如果某些外部库/调用可以返回空值值，结果应立即包装可选的/选项/也许。
无需任何额外的努力，严格遵循上述约定即可编写Java代码，该代码包括：
- 永不抛出空指针异常并拥有所有空值值处理正确。clearly and explicitly distinguishes 空值able and non-空值able values in code and lets compiler enforce this distinction at compile time.
扫一扫
281
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
