因此，Guava 具有简单而有用的前提条件来检查方法参数。但我想也有一个“后置条件”类是合理的。还是仅仅是因为 java 提供了断言？
由于不存在这样的课程，在数学返回之前检查后置条件的“最佳”（实践）替代方法是什么？
问问题
2706 次
3 回答
16
测试后置条件将是多余的。我们在java中测试后置条件的方式是单元测试。
通过单元测试，我们确保对于给定的输入，我们得到可预测的输出。有了Preconditions，我们可以验证我们是否有有效的输入，因此测试已经保证了输出。
于 2012-10-20T20:12:22.200 回答
15
我会assert在方法本身中使用 Java 关键字来编码后置条件。
单元测试还是后置条件？
单元测试和后置条件服务于不同的目的。
单元测试中的断言提供了对一个输入向量的方法结果的检查。它是一个预言机，指定一个特定案例的预期结果。
assert 方法本身中的An验证对于任何输入，后置条件都成立。它是一个预言机，指定所有可能情况的预期结果（属性） 。这种作为预言机的后置条件与自动化测试技术很好地结合在一起，在这些技术中，很容易生成输入，但很难为每个输入生成预期值。
番石榴后置条件？
至于为什么 Guava 有 Precondition 类，但没有 Postcondition 类，这是我的理解。
Guava Preconditions 有效地为您希望根据方法的输入或对象的状态抛出特定类型的异常（非法参数、空指针、索引超出范围、非法状态）的常见情况提供了许多简写。
对于后置条件，此类常见情况较少。因此，不需要提供速记来抛出特定类型的异常。一个失败的后置条件就像一个 HTTP 500“内部服务器错误”——我们所知道的就是执行我们的方法时出了点问题。
（请注意，Guava 的前提条件概念与纯按合同设计的概念完全不同，后者根本无法保证如果不满足前提条件 - 甚至不会抛出合理的异常。Guava 的 Preconditions 类提供了有用的使公共 API 更具防御性的能力）。
于 2013-02-20T20:27:51.847 回答
9
前置条件和后置条件的用途非常不同。
Preconditions 测试输入，它不受方法的控制；后置条件测试输出，即。因此，它们在方法本身内部没有意义，而只是作为测试方法的外部代码。
然而，如果你真的想在你的代码中加入这样的断言，那么 Guava Preconditions 也可以很好地实现这一点，即使这不是它们的预期目的。
于 2012-10-20T20:13:38.887 回答