• 2014-05-28

    服务端软件设计(二)

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/271628808.html

    数据,是软件处理的核心,我们写各种各样的应用都是为了处理数据。处理数据有一个非常重要的前提,数据是合法的。一个计算数字的应用如何面对一堆字符呢?为了保证应用可以正常运行,各种校验是必不可少的。

    问题来了,校验该在哪做呢?

    显然到处做校验不是一个好主意,那到底服务层、数据层,还是接口层,才是校验的藏身之所呢?

    为了不让校验四处进行,一个建议的做法是在数据的入口进行校验,保证所有进入系统的数据都是合法的,这样一来,所有逻辑处理的代码只要关心逻辑就好了,而不需要关心数据合法性。比如说,客户端请求就在请求到达的入口进行校验,而从数据库读出的内容,就在数据层进行校验,而如果是集成了其它的服务,则要在读回数据的地方立刻进行校验。数据一到系统,先进行校验,如果有错了,就会立即发现,而不是等到数据跑到了程序里面,出错了,我们再去定位数据的来源,这种做法符合我们常说的“Fail Fast”原则。

    有一个有趣的问题,作为一个对细节特别较真的程序员,如果我的数据是字符串,虽然你说你在接口部分校验了数据,万一你遗忘了,流到了我这里,我不放心啊!所以,我可能还要在我这里写一遍校验。

    对于这个问题,我只能说,谁让你把字符串到处传了?

    事实上,在开发初期,很多东西用字符串表示起来很简单,比如语言,比如Tag。这种不精心的实现就会给未来带来很多麻烦。正如前面这个问题,其实大多数时候,你需要的不是一个字符串,而是一个“东西”,它应该被封装起来。所以,与其纠结于这个字符串是否还要校验,请考虑封装。

    另外一个有趣的问题是,如果我这个数据允许为空怎么办?想想都头疼,到处判断一个对象是否为空。

    如果我们能分清能为空的对象和不能为空的对象,那就再好不过了。幸好我们有了Optional,它给我们提供了一个有意义的空。结合前面的内容,在接口部分,如果数据可能为空,我们就用Optional把它包装起来,而普通对象则直接传递。我们就在程序里有了一个约定:

    • Optional的对象可以为空,需要判断的时候,自己处理一下。
    • 普通对象都不能为空,为空就直接空指针异常,因为那是错的。

    关于Optional,我强烈建议每个Java程序员都去了解。在Java 8里,它已经成为了JDK的一部分,如果你的Java版本还早,Guava做了很好的支持。

    分享到:

    历史上的今天:

    引用地址:

    评论

  • 好像无法发送代码例子讨论。

    我现在正在试着用JDK8的Optional来重构代码,
    但是Optional并不是我想象的那么完善,
    如果一个是空对象,还是认为是存在的