在公共方法中检查参数的先决条件
我要问你关于设计问题的观点。
问题基本上如下：一个对象的公共方法应该总是检查其输入参数中的前提条件，还是爱对调用者的责任和“相信流量”更好？
我并不是在谈论明显的先决条件，比如检查null以避免空引用异常，但我指的是方法参数中的业务前提条件。 这种典型的情况发生在DDD服务中，它对输入参数执行某种验证，并返回包含关于该验证的反馈的对象。
作为一个例子，考虑一个CheckPerson类， CheckPerson具有Person类型的单个参数的公共方法PerformCheck 。 想象一下，有一条商业规则说这张支票对金发人士来说没有意义。
在我看来，这个检查很重要，方法名应该反映这个规则（像PerformCheckForNonBlondePerson ）。
我应该添加这些检查吗，还是我应该信任呼叫者？
是的你应该！
您需要区分输入验证和预设条件 。 业务规则，正如你所描述的那样，可以同时应用于两者。
输入验证发生在系统边界。 您希望在某些情况下输入验证失败。 发生这种情况时，您应该向客户指出错误并提供有用的错误描述。
另一方面， 先决条件是系统中某个方法（或整个组件）合同的一部分。 您总是希望确保遵守此合同，否则您的实施可能会错误地执行。 在这里，我们使用警卫来执行前提条件。 一个守卫应该总是通过。 如果没有，它总是程序员错误（而不是用户错误）。
@theDmi感谢您分享您的观点。
我完全同意你的立场。
我目前工作时的环境是由三个人组成的团队，实施一个大型应用程序，并将大量业务逻辑和领域规则考虑在内。
我不同意“信任流程并将责任委托给调用者”这一理念的主要原因是，这迫使每位将要致电域服务的开发人员明确阅读此类服务的代码，并且对该代码背后的业务需求有很好的了解。
在我看来，这是不现实的，而且这是一个容易出错的过程。
大型应用程序中的域层被我们要编写的每一个应用程序逻辑调用，并且将所有责任留给调用者在我看来都是非常危险的。 我们目前不使用任何类型的图书馆来执行先决条件检查，但我知道有几种选择:)
上一篇: Checking preconditions on parameters in public methods
下一篇: Service layer: What to return if query argument is null?