Null Object 模式之我见

写了个cache服务器的抽象层，如果cache中不存在该对象，我就让它返回null。

public Person fetch(String name){
    //do some thing.can not find the Person.
    return null;
}

 

头说这么不对，专家建议方法尽量不返回null,让我设置一个常量代替null,这叫 Null Object模式，于是又改成下面这样：

public Person fetch(String name){
     //can not find the Person
     return Person.EMPTY_PERSON;
}

 

据说这种模式有两个好处:

1。减少if的判断语句。
2。提高程序的健壮性,会少很多NullPointer错误。

确实，NullPointer错误应该是所有的java程序员遇到的最多的一个错误，也是比较让人头痛的错误。那次在论坛上看见一个人叫做NullPointer，我看见都很头痛。

但是这种模式真有这么神奇，可以完全消除null么？
现在我们从cache里获取了一个Person对象,要用它，那需不需要判断一下它是不是EMPTY_PERSON呢？如果需要，它和null有什么区
别？不就相当于重新定义了一个类型只能为Person的null么。如果使用者忘记检查了，直接当Person用，会有什么结果？比方调用
person.getName()，返回什么?null？这不还是会有NullPointer么，那返回空字符串?但要是更复杂的对象呢？比方要获取
Person的父亲，person.getParent()，返回什么？还是返回EMPTY_PERSON？那要是程序里要是想遍历一下person的族
谱，不就进入死循环了么。

于是我又搜索了一下相关文章,发现Null Object 模式用在下面两个场景里确实有作用：于是我又搜索了一下相关文章,发现Null Object 模式用在下面两个场景里确实有作用：

1。一种是返回集合的时候。如果返回集合时返回null，我们就必须多做一步判断：

List persons = personCache.fetchAll();
if(persons!=null){
    for(Person p:persons){
        p.doSometing();
    }
}

 但如果返回的是一个空集合，我们就不需要判断是否为null了。
2。另一个场景是在策略模式(Strategy Pattern)或者状态模式(
State Pattern)中。这两种模式下，都是要根据一定的策略或者状态进行不同的操作，这种情况下设置一个默认的do nothing的Null Object很有用。

 

Null Object就相当于数学上的0,它本身代表nothing，起个占位的作用，对任何操作都没有影响(当然，个别例外是可以容忍的,比方0不能做除数)。0加10000次还是0。Null Object只有在这种情况下使用才是合理的。简单的一个判断方法就是你是否能把NullObject当一般对象使用并且不影响程序的逻辑和结果。如果回答是，则使用NullObject，如果回答否，则说明这个场景不适合Null Object模式。像我开始提到的那种场景就不适合使用Null Object 模式。

最后在探讨点题外内容。如果没法用Null Object，那就只能返回null了？使用者要是忘记检查是否为null就使用，不就会有令人头痛的NullPointer错误了么？还有一个办法就是抛出强制检查的异常，逼迫使用者拦截异常进行处理。不过这种方式也有很多争议，Hibernate的接口就引起了这样的争议。想象如果从Map里获取对像的时候，如果不存在就抛出异常，那是个多痛苦的事情。曾经用过一个JSON库（好像就是官方那个），如果json里没有那个属性，它就抛出异常，导致我用的很痛苦。

另外还有一个问题就是java的方法签名设计没有体现出对返回结果的约束。比方获取map中不存在的对象会返回null，这样的信息只能从文档中得知，从签名上看不出来。同样，从签名设计也看不出来参数是否可以为null，或者是否有其他限制（比方必须是大于0的整数）,只有通过看文档或者运行后得到非法参数的错误后才能知道。主要原因就是java没有内置实现 契约式设计（Design by Contract）。当然，虽然java语言中没有内置这种功能，但还是有其他实现途径,Contract4J,就是用java 5的annotation来实现契约式设计的。

 

rel：http://jolestar.com/1245332724302/