再一次苦B程序猿和苦C程序猿结对话发生编程周期

此代码：

苦C程序猿：会什么你的每一个方法都要去检查一下參数是不是null，參数是不是指定的几种可选数据?

苦B程序猿：由于假设我不检查，后面的操作将会是对一个错误的对象进行，会影响程序的正确运行。

苦C程序猿：可是这种方法应该仅仅关注自己的业务逻辑而不应该做一些与业务无关的參数的正确性推断，否则这种方法可能10行中有7行都是做參数合法性验证，真正的业务可能仅仅有3行，你不认为这会非常怪异吗？

苦B程序猿：那我有什么办法。我的程序跑不下去了。測试来找我的麻烦了！

苦C程序猿：我看你的每一个方法都要对參数做合法性检查，那能否够将这样一个行为提取出来使全部的方法在被调用之前让一个类去做參数的合法性检查，我们仅仅要给參数一个说明比方这样

苦B程序猿：嗯，这样看起来非常不错，我们能够利用spring的aop做个拦截，在全部的方法被调用前先让一个拦截器来检查全部的參数是否合法。

苦C程序猿：对，我们就这样干。

 没多久时序图片就出来了。

.

.

.

半天后。两个人仅仅有一个想法。那就是太苦B了，这是一整个体系两个人一天怎么做的完？在项目的时间进度压力下两人仅仅有放弃（看来非常多情况下不是程序猿不想把事情做好。时间、时间、还是时间），于是程序又回到了刚開始，而且他们不得不为这一次冒险所耽搁的时间去自己加班完毕工作。

这种事情发生的多了大家就再也不会想在项目里使用什么优美的方式或好的模式来编写与设计代码了，而是以完毕功能为目地的编码。

回想上面的对话我们发现

Ø 苦B程序猿的做法，是为了防止程序出现异常而对输入參数为了检查。

Ø 苦C程序猿的想法，是让这样的检查工作不必分散到各业务方法中。

两个程序猿都是想把程序做的更健壮、业务更清晰、职责更分明。可是因为客观的原因他们的努力失败了。

神的出现

继续上面，此时的苦C程序猿依旧没有放弃。他利用项目的空暇时间继续研究，他觉得这样的需求应该不仅仅他一个人有。世界上还有那么多的苦X程序猿，可能早就有人想到了这个需求，或许早就有人已经完毕了这个工作，苦C程序猿突然想起了spring的mvc中好像能够验证參数的正确性，于是他求助了万能的google大神，最终被他找了解决问题的究极方案。

当当当“JSR303”闪亮登场。http://jcp.org/en/jsr/detail?id=303

这个规范当前较好的实现是Hibernate Validator，http://www.hibernate.org/subprojects/validator.html而且也可较方便的与spring集成。

此时的苦C程序猿感觉到浑身充满了力量。他大叫一声“JSR303赐予我力量吧！Google,live for ever”。

从此苦C程序猿在开发这条苦B的不归路上走的更坚实了，由于他又多了一把称手的神器—“JSR303”。

苦B程序猿和苦C程序猿皈依了我神终于升华为苦A程序猿

网上有这样一个样例https://github.com/ghillert/spring-hibernate-validator-sample，这里面就是讲述怎样使用JSR303来验证方法參数的。这里面须要在spring中做例如以下配置

关键就在MethodValidationPostProcessor这个类。它的作用就是给全部的标记了要做验证的接口加入一个org.springframework.validation.beanvalidation.MethodValidationInterceptor拦截器。这个拦截器会负责验证你所要验证的參数。

但这个拦截器会抛出一个org.hibernate.validator.method.MethodConstraintViolationException.MethodConstraintViolationException异常。对于有些人来说或许他们并不希望得到这种异常。可能是由于这个异常长的太怪异，也可能是其他的原因，总之就是不希望用这个,他们希望自已来控制验证出错后的处理方式。谢天谢地这一切都是开源的（感谢天。感谢地，感谢Spring……熟悉的旋律出如今耳边）。那么分析MethodValidationPostProcessor与MethodValidationInterceptor代码后我们能够非常easy的做到这一点，聪明的程序猿们应该非常快就能够明确了。

苦C程序猿以最快的速度将这个消息告诉了苦B程序猿，苦B程序猿得到这个消息后第一直觉就是要尽快将这个成果分享到整个团队中，于是不久后整个团队的成员都皈依了我神（JSR303）终于升华为了苦A程序猿（为什么还是苦A程序猿？因为有新的麻烦将继续出现，我勒个去……）。