如何做到宽容的收 | 重归混沌的BLOG

如何做到宽容的收

在《unix编程艺术》提到过,Postel规定过:“宽容的收,谨慎的发”。

当时看到这一段话时,并没有多加思考,以为仅仅是对于网络协议多加检查就好了,并没有深想。

然而经过这两年的实践,我发现其实这条准则可以适用于更多的领域。

对于一个进程来说,他的输入可能是标准输入、管道、网络、配置文件等这些外部输入源。

那么进程所表现出来的宽容就是,不管从外部输入源接收到任何数据,都不应该影响程序的正常执行。即不会由于错误的数据格式或内容,造成崩溃,污然数据等副作用。

实现没有外部输入源程序时,我习惯上会信任设计正确的数据。

即,设计上在使用这个数据时,数据是合法的,那么一般不会再多加检查是否合法,最多加个assert去保护一下。

因为我觉得如果设计上正确的数据,如果出了问题,一定是设计出了问题,加上数据有效性检测并不能解决根本问题。此时需要做的是去修正设计,而非在局部打补丁。

而第一次接触到有外部输入源程序的那一段时间,由于没有经验,并没有区分哪些是内部数据,哪些是外部数据。所有的数据只要是设计正确的,全部都被信任,以至于在输入非法数据时,逻辑错误,数据紊乱。后来简直是草木皆兵,所有使用数据的地方都对其进行合法性判断。

经过几次实践并思考之后,发现其实可以将整个进程提象成一个整体,所有的外部输入源可以抽象成几个可以流入数据的口子。

然后抽象出一个筛子层,将筛子置于各外部输入源的口子处。筛子层负责对口子输入的数据进行仔细校验合法性,以确保通过筛子的的数据都是有效的合法数据。

由于所有的外部输入数据已经经过筛子过虑, 在此在实现真正的逻辑层时,完全可以和以前一样,直接信任设计正确的数据。这样在写逻辑代码时就不再需要提着思想的包袱,时时刻刻想着是否需要验证数据的合法性了。可以让我们更专注于逻辑设计本身。

然而,由于外部数据的合法性校验必然与具体逻辑密切关联,因此筛子层必然与逻辑层耦合在一起。

不过提象出筛子层的意义并不是用于与逻辑层分离。而是为了抽象出一个屏障,以清晰指明,哪些数据是由外部输入得来,需要仔细判断是否正确,哪些数据是程序内部自己产生,可以完全信任。

此准则不仅仅适用于进程,还适用于框架和库。

一般来说一个框架或库,一定是用于解决某个问题而生的。 即然抽象成框架或库,那么一定是希望别人能够快速使用,并且尽可能的屏蔽细节。因此,我们可能仅仅使用框架提供有很的几组API就可以实现一个很强大的功能。

但是由于这样或那样的原因,可能别人在开发过程中并没有完全领会这组API的输入数据的要求。如果框架不能宽容的收,框架的使用者就可能面临着很艰难的局面。

框架宽容的收,并不是说像进程收到非法数据一样,保证进程的稳定运行。由于框架是向业务逻辑提供功能的一个组件。因此,如果框架被误用,必须要尽快的将问题暴露出来。

因此,我觉得框架的宽容,应该仅仅保证不会因为非法数据造成误动作及污染数据等副作用。在一些特殊的情况下是可以直接崩溃,以尽快提醒业务逻辑的实现者此处的错误。

总而言之,不管是对于进程还是框架,只要是一个完整的个体,一定是自成闭环的。即,只靠自己个体内的数据,就有足够的能力确认当前外部输入数据是否合法。



发表评论