重复参数检查功能

Question

我经常调用层次结构,因为所有方法都需要相同的参数.如果我不想把它们放在实例级别(类的成员)那么我总是问我是否有意义检查每种方法中它们的有效性.

例如:

public void MethodA(object o){
   if(null == o){
      throw new ArgumentNullException("o");
   }
   // Do some thing unrelated to o

   MethodB(o);

   // Do some thing unrelated to o

}

public void MethodB(object o){
   if(null == o){
      throw new ArgumentNullException("o");
   }
   // Do something with o
}

如果MethodA使用参数,那么它清楚,我必须检查那里的有效性以及MethdoB.但只要方法A没有做任何事情而o不是给予它MethodB,那么检查有效性也是好的做法MethodA.

同样检查的优势MethodA可能是被调用者调用的方法中的异常抛出,这很好,但是有必要吗？调用堆栈也会说明这一点.也许它有意义的公共,内部,受保护但不是私人方法？

我以null检查为例,但索引验证或范围验证也属于自我问题,但我认为由于冗余代码的危险性存在限制.你怎么看？

UPDATE

通过AakashM的回答,我看到我的确很精确.MethodA不仅是电话MethodB,还有其他事情但与之无关o.我添加了一个例子来澄清这一点.谢谢AakashM.

Answer 1

Steve McConnell的Code Complete讨论了" 街垒 " 的概念- 一道防御墙,其中数据不受信任,数据在其中受信任.想要进入街垒的数据必须经过验证过程,但在街垒内,数据可以通过验证码自由移动.

如果你可以在你的项目中强加这么多的结构和分层,并坚持下去,它确实会使内部的路障代码有更少的仪式和更多的本质.但是,只需要一种方法就可以通过障碍来解决所有问题.

在你的例子中,MethodB是public.这意味着您没有自动将来的保证,这MethodA将是它唯一的调用者 - 因此我会说它的验证代码应该保留.private但是,如果它是在课堂上,你可以提出删除它的论据.

至于MethodA,如果它实际上除了调用之外什么都不做MethodB,它就不应该存在.如果它是未来扩展的存根,并且在某些时候它将会执行某些操作o,那么它的验证代码也应该保留.