嗯,这是一段时间以来这个问题被张贴,但我想给一个不同的角度对这个话题。
使用你发布的具体例子,恕我直言,你应该做验证,但以不同的方式。
实现验证的关键在于问题本身。想想看:你在处理的是名字,而不是字符串。 字符串是非空名称。我们还可以考虑使字符串成为名称的其他特征:不能为空也不能包含空格。
假设您需要添加这些验证规则:如果您坚持使用您的方法,您会像@SingleShot所说的那样结束混乱。
另外,如果多个域对象有一个setName setter,你会怎么做? 即使您使用助手类作为@dave,代码仍会被复制:调用助手实例。
现在,想一想:如果您在setName方法中能够接收到的所有参数都有效,该怎么办?当然不需要验证。 我听起来过于乐观,但可以做到。
记住你正在处理的名称,所以为什么不建模名称的概念? 这里的香草,虚拟实现,以显示想法:
public class Name
public static Name From(String value) {
if (string.IsNullOrEmpty(value)) throw new ...
if (value.contains(' ')) throw new ...
return new Name(value);
}
private Name(string value) {
this.value = value;
}
// other Name stuff goes here...
}
因为验证在制定的过程中发生的事情,你只能得到有效的名称实例。无法从“无效”字符串创建名称实例。 不仅验证代码已经集中,而且在对它们有意义的上下文中引发异常(创建Name实例)。
您可以阅读Hernan Wilkinson的“巴塔哥尼亚背后的设计原理”中的伟大设计原则(该名称示例源自它)。请务必检查ESUG 2010 Video和presentation slides
最后,我想你可能会发现Jim Shore的文章"Fail Fast"有趣。
看起来您的质量检查人员没有针对这些支票投放分支获得单元测试覆盖率。你应该告诉他们停止懒惰,并且将其包含在测试中,因为它应该是。 – 2009-10-30 19:59:59
单元测试?我们不需要单元测试......(我知道,我知道,但我不能改变一切......) – 2009-10-30 20:03:27