项目心得

        这次项目因为好几个人合作，然后每个人的模块直接联系比较多，所以暴漏出来的问题也比较多，我想在此记录下。

        其实都很简单微小但是也很重要，首先看第一个：

        1：关于返回值的判断问题

         A调用B提供给他的接口 XXXServcie  的XXXDoSomething方法，返回值是一个List，一般情况下这个list都不为空，但是在某些情况下他为空，这时B返回给他的是个null的list（并不是B想直接return null 而是B可能调用的另外的service直接返回的就是null B做了一个转发的功能而已）A每次调用不管是一般情况还是特殊情况都没有对B的返回list做null检查，然后在特殊情况下出现了不想到看到的NullPointException ，试问出现这个异常你觉得好受吗 我是不舒服的，好比让你拿着武器去打仗，武器没给你，你就扣动了你认为的存在扳机，那肯定你挂的很惨。先不说到底是谁的问题，也许你会说A应该判断的，其实我也觉得是A的问题，但是其实更深的层次考虑是合作双方直接的契约没定好，你不能返回一个null 就算没值你也得给我一个空的list也好，其实换作返回一个Object也一样，到底是null还是一个空的Object，这个都是要先约定好，因为每个人的编程风格不一样，我更倾向于给我一个null，我自己调用的时候判断下。看过一篇文章有讲过这个例子的，例子说 2个人合作接口编写，一个人给另一个人说他的接口绝对不返回null的 会给个空的，但是一次他返回了一个null，那另一个人没加判断null的操作，因为他知道约定了他不返回null的，然后挂的很惨，文章的作者这么评价的：“不要太坚信接口的另一方给你的一个约定，保险的方式还是要自己判断下约定的成立条件”。是的即使是约定我们也要判断下，简单的一个null的判断至少不会让你看到NullPointException的尴尬。不过这个又引入了新的问题，现在的层次调用模型里你加入了太多的判断会显得杂乱，但是为了健壮性而打乱美观我想也是必须的，因为你不知道谁会调你的接口然后给你个null 直接让你挂在那个接口上。

        针对list的判断 我现在的做法比较啰嗦 首先判断 是否为null 然后判断size是否大于0 然后是每个元素是否为null 。其实在一般的应用中元素为null 也没什么，但是如果你的应用中这个元素不能为null的话 你一定要加判断，否则造成的损失真的很大。

     2：对于对象的简单和重用问题

         我习惯于一个接口完成单一的一个功能，当功能很类似的时候我可以抽取出公共的部分，但是我不想都写一个接口里，搞的他是万能的接口一样。的确很多相似的功能都用一个接口来实现，那可是相当的重用，但是我觉得至少这个接口的功能并不是很明晰的表现出来。我喜欢小小的接口，能完美的表现出他的功能。有的时候是让业务清晰点好 还是让代码清晰点好呢，真的需要考量。