转自：这里写链接内容

这几天在看设计模式，看到一个观点，就是在需要返回值的方法中，使用空对象（empty object）来代替返回null。理由很简单，空对象与其他有意义的对象一样，使得调用方法的用户不需要区分返回值，即不需要判断返回值是否为null，从而简化了客户端调用（不必在使用返回值之前进行 if 判断）；另外也使得客户端的代码更不容易出错（如果有粗心的程序员或者自己忘了判断null）。

我觉得这又是一个很纠结的问题，我现在在做的项目就饱受这个问题带来的痛苦。在当前的项目中，几乎所有的方法（项目中创建的）都使用null返回类型，不管是String还是集合类。例如：

这样就造成所有使用到这个方法的地方都要在使用返回值之前进行null判断，比如for循环之前，比如retainAll()之前，比如size()之前。

这还不是最痛苦的，最痛苦的是，并不是所有的方法都返回null，有的地方返回的是一个空的ArrayList。这种方法有一些是项目内的，有一些是第三方类库的。于是，为了健壮性，不管3X7=21，对于任何方法的返回值，在使用前都先进行null判断，天知道其他人会不会在下一刻就把方法的返回值从空对象变成null了。所以，一翻开代码就能看到大批的if语句，如果再跟一些条件语句和for语句混合在一起，简直就是灾难。

那究竟该如何面对这个问题？在什么地方应该返回null，什么地方返回空对象？

1.对于集合和数组作为返回值，使用长度为零的数组或者集合，而不是null。

这样做的好处实在太多了：a.简化代码，不需要调用者在使用返回值之前进行null判断，不管是size()，for()，集合操作都OK。b.增强程序的健壮性，既然返回值不是null，就不用担心NullPointer这个无处不在的异常。

反对者一般都从性能的角度来考虑，认为这样增加了系统的开销。对于这一点，我觉得挺有意思，我见过太多的程序员写出来一些很不好的设计，例如很烂的异常处理与算法循环，但是他们却对于这个空集合十分在意。我本人对于性能没有太高的sense，我觉得对于像我这种仅仅勉强能保证程序健壮性的菜鸟来说，过多的考虑性能问题是不实际的。我不仅没有那个能力，并且很有可能把事情做的更糟。这里借用Effective Java书中的话，在这个级别上担心性能问题是不明智的，除非分析表明这个方法正是造成性能问题的真正源头。

我们还可以在程序中返回可重用的空对象，例如一个长度为零的数组或者是emptyList/emptySet(这些都在Collections类中定义)，这样，在我们整个程序周期，都会只分配这一个空对象。当然，这里有个问题，如果你返回的List将来还希望有修改的操作，例如:

那么返回Collections.emptyList()就是不合理的，整个空集合并不能修改，它并不是一个ArrayList或者LinkedList，它仅仅是List接口的一个实现。

2.字符串作为返回值，使用空字符串来代替null。

我们经常有方法返回字符串，很多时候都会进行字符串的拼接或者equals或者split等，如果返回值为空，我们就必须进行null判断。对于字符串拼接，倒不会报出NullPointer异常，但是会被当成”null”来使用，这更诡异。例如：

3.任何在逻辑上表示查找(search或者get)的意思时，应该返回null。

例如下面这个方法就是不合理的

4.当空对象与其他返回对象有一样的行为和意义时，使用空对象

例如，有一个方法返回一个迭代器。一个空的迭代器可以定义为NullIterator并实现Iterator接口，他的next方法永远返回null，他的hasNext方法永远返回false。这样，使用这个方法返回值的代码就不要进行null判断，因为NullIterator的行为与其他迭代器一样。

光谈到使用的场合还不够，对于项目而言，还需要项目约束来制约开发者的行为，否则必然是一团糟，因为谁都不相信谁。