问题
...if (!= null) {.();}...
最终项目中会出现大量空代码，丑陋且复杂。 。 。 如何避免这种情况呢？ 短期判断是否被滥用？
很多业务场景都需要我们在特定时刻做某项任务，定时任务就解决了这种业务场景。 一般来说，系统可以使用消息传递来代替一些定时任务。 两者有很多相似之处，可以互相替换对方的场景。
基本答案
这是初级和中级程序员经常遇到的问题。 他们总是喜欢在方法中返回null，因此在调用这些方法时，他们必须测试是否为null。 另外，也许是受到这种习惯的影响，他们总是下意识地认为所有的回报都是不可信的，并且为了保护自己的程序，他们添加了很多误报。
吐槽完毕，我们回到主题本身：
在做出判断之前，请区分以下两种情况：
1. null 是一个有效且有意义的返回值（其中 null 就 ; 而言是有效的）
2. null 无效且不正确（如果它不是有效的。）
你可能还不明白这两句话的意思。 别担心，继续阅读。 接下来，将详细讨论这两种情况。
先说第二种情况
如果 null 是不合理的参数，则应显式中断程序并抛出错误。 这种情况在 API 方法中很常见。 比如你开发一个接口，id是必填参数，如果调用者不把这个参数传给你，当然不行。 你需要意识到这种情况，并告诉调用者“嘿，伙计，你为什么不将 null 传递给我呢？”
与null语句相比，有两种更好的检查方法：
(1)语句，你可以把错误原因放在参数中，这样不仅可以保护你的程序不宕机，还可以将错误原因返回给调用者。 这不是一石二鸟吗？ （原文章介绍其用途，此处不再赘述）
(2)也可以直接抛出空指针异常。 上面说过，此时null是一个不合理的参数。 有问题就有问题，就应该公开扔掉。
第一种情况比较复杂。
在这种情况下，null 是一个“看似”合理的值。 比如我查询数据库时，某个查询条件下没有对应的值。 这时null就可以看作是表达“空”的概念了。 面试指南：/
以下是一些实用的建议：
1、如果方法的返回类型是，当返回结果为空时，可以返回一个空列表，而不是null，这样调用方就可以大胆地处理返回。 例如，调用方得到 后，可以直接打印 list.size() ，而不必担心空指针问题。 （什么？当你想调用这个方法的时候，你不记得之前实现这个方法的时候是否遵循了这个原则？所以，编码习惯非常重要！如果你养成了这样写代码的习惯（返回空而不是返回空） null），你在调用自己写的方法时，可以大胆忽略null测试）
2、返回类型不正确怎么办？
然后返回一个空对象（不是空对象）。 这是一个例子。 假设有如下代码：
{ 空白 （）;} { （ ）;}
其中，Parse有一个接口，会根据用户的输入查找并执行相应的操作。 如果用户输入不正确，可能会找不到对应的()，因此会返回null。 当接下来调用该方法时，将出现一个空指针。
解决这个问题的一种方法是使用Null（空对象模式）
改造后
类定义如下。 这样定义方法后，就保证了无论用户输入什么，都不会返回null对象。
类 { = new () { void () { /* 做 */ } }; ( ) {// ...if ( /* 我们找不到任何 */ ) { ;} }}
比较下面的两个调用示例
1、冗余性：每次获取到一个对象，就判断为空。
= .();if (== null) { // 现在怎么办？ // 这将是其中 null 不是（或不是）有效的 } = .();if ( == null) { // do } else { .();}
2. 精简
.().().();
因为无论什么情况，都不会返回空对象，所以拿到之后就可以放心调用该方法了。
精选其他答案：
1.如果要使用equal方法，请使用.equal())
例如使用：
“酒吧”。(foo)
代替
foo.(“酒吧”)
2、java8或者guava lib提供了一个类，它是一个元素容器，可以封装对象，减少空判断。 不过代码量还是蛮大的。 准确的。
3、如果要返回null，请停下来想一下这个地方是否应该抛出异常。
