在什么时候对参数进行验证

private 只在类中应用，你可以控制它；其他的就不好说了

我同意，
private不可以反射吗？

两派观点

1 宽进严出 防御式
2 严进严出 DbC

我更喜欢service上验证，谁的方法谁负责验证，调用的人怎么知道你要的参数是什么呢。

调用的都不知道，那还调用个啥啊。

如果是买东西。你都不知道自己买啥。那你还去干嘛啊。。。

不知道这个问题有什么可以纠结的~

首先人家是想规避《 冗余验证 》才去问应该在哪层做验证！是要解决这个问题，是要谈论怎么样 能规避这个问题！

而不是问，是不是所有的方法都该做验证这个问题。

其次，一个项目，如果 架构师 对数据验证的位置没有简明的标注 ， 我只能说这个架构很不负责任 。

从设计上来说，很多大的方法会拆分成很多小的方法的话，岂不是所有的小方法都需要进行验证。如此以来，复用岂不

会照成代码冗余？这不是和复用的初衷背道而行吗？

现在假设所有的公共方法都加入数据有效的验证的话 ， 那么冗余的验证代码会有多少？

每个人是该对自己的代码，对自己的方法负责任。 但是数据验证的位置，不应该在具体的方法内部（特例除外）

个人觉得架构师应该吧《数据有效性验证》放入一个基础中，在action中做《入口验证》，service中做《业务逻辑验

证》，工具类尽量的少做验证。

这样才能尽量减少 冗余验证的出现。

与其说：“要对自己的方法负责”，我更觉得应该《对整个程序负责》更准确些。

鄙人一些浅见 ， 轻拍

赞同，不要为了形式而形式，系统外入口都要验证，系统内部没必要，内部可以通过管理来达到

LZ所言差矣，什么时候验证都行，关键在于service方法是不是只有action方法调用，想清楚这个好办了

楼主这个帖子非常有意识，如今竟然没有一个“隐藏”或者“新手”贴，我投个良好

 

谢谢了哈，在javaeye发贴，是要做好被投“隐藏”和“新手”的准备。