我喜欢Nat Pryce的文章。以下是链接：

用多态调度避免空值避免使用“告诉，不要问”风格的null

在文章中，还有一个指向Java Maybe Type的Git存储库的链接，我觉得这很有趣，但我不认为单独使用它会降低检查代码膨胀。在互联网上做了一些研究之后，我想主要通过仔细设计可以减少空码膨胀。

函数方法可能有助于包装重复的空检查并执行匿名代码，如下面的示例。

    BiConsumer<Object, Consumer<Object>> consumeIfPresent  = (s,f) ->{
        if(s!=null) {
            f.accept(s);
        }
    };

    consumeIfPresent.accept(null, (s)-> System.out.println(s) );
    consumeIfPresent.accept("test", (s)-> System.out.println(s));

    BiFunction<Object, Function<Object,Object>,Object> executeIfPresent  = (a,b) ->{
        if(a!=null) {
            return b.apply(a);
        }
        return null;
    };
    executeIfPresent.apply(null, (s)-> {System.out.println(s);return s;} );
    executeIfPresent.apply("test", (s)-> {System.out.println(s);return s;} );

public static <T> T ifNull(T toCheck, T ifNull) {
    if (toCheck == null) {
           return ifNull;
    }
    return toCheck;
}

有时，您可以使用对其参数进行操作的方法来定义对称操作：

a.f(b); <-> b.f(a);

如果你知道b永远不可能为空，你可以交换它。它对equals最有用：而不是foo.equals（“bar”）；最好使用“bar”。equals（foo）；。

我高度无视建议在任何情况下使用空对象的答案。这种模式可能会破坏合同，将问题埋得越来越深，而不是解决问题，更不用说使用不当会产生另一堆需要未来维护的样板代码。

实际上，如果从方法返回的某个值可以为空，并且调用代码必须对此做出决定，那么应该有一个更早的调用来确保状态。

还请记住，如果不小心使用，空对象模式将占用内存。为此，NullObject的实例应该在所有者之间共享，而不是每个所有者的unigue实例。

此外，我不建议在类型是原始类型表示的情况下使用这种模式，比如数学实体，它们不是标量：向量、矩阵、复数和POD（普通旧数据）对象，它们是用来以Java内置类型的形式保存状态的。在后一种情况下，您将以任意结果调用getter方法。例如，NullPerson.getName（）方法应该返回什么？

为了避免荒谬的结果，值得考虑这样的案例。

另一个建议是防御性地编程——类/函数提供已知且安全的默认值，并且为真正的错误/异常保留null。

例如，如果函数在出现问题时（例如将数字转换为字符串）返回空字符串，请让它们返回空字符串（“”）。在继续之前，您仍然必须测试返回值，但对于异常没有特殊情况。这种编程风格的另一个好处是，您的程序能够区分正常操作和异常，并做出相应的响应。