问题标签 [design-by-contract]

我没有看到很多开发人员使用 Java Assert，但我非常热衷于使用它们。您能分享一些有效使用它们的技巧吗？

从表面上看，对象初始化器似乎给 .net 4.0“代码契约”带来了问题，其中通常应该在对象构造函数完成时建立不变量。然而，据推测，对象初始化器需要在构造完成后设置属性。

我的问题是“代码契约”的不变量是否能够处理对象初始化器，“好像”属性是在构造函数完成之前设置的？那真是太好了！

在探索这些问题时，我最近发现了assertJava 中的关键字。起初，我很兴奋。有用的东西我还不知道！一种更有效的方法来检查输入参数的有效性！耶学习！

但后来我仔细看了看，我的热情并没有因为一个简单的事实而被“磨平”而是“完全熄灭”：你可以关闭断言。*

这听起来像是一场噩梦。如果我断言如果输入是 ，我不希望代码继续listOfStuff运行null，那么我到底为什么要忽略该断言？听起来如果我正在调试一段生产代码并怀疑它listOfStuff可能被错误地传递了null但没有看到任何日志文件证据表明该断言被触发，我无法相信listOfStuff实际上发送了一个有效值；我还必须考虑断言可能已完全关闭的可能性。

这假设我是调试代码的人。不熟悉断言的人可能会看到这一点并假设（相当合理地）如果断言消息没有出现在日志中，则listOfStuff不会是问题所在。如果你第一次遇到assert是在野外，你会不会想到它可以完全关闭？毕竟，它不像有一个命令行选项可以让你禁用 try/catch 块。

所有这些都让我想到了我的问题（这是一个问题，不是咆哮的借口！我保证！）：

我错过了什么？

是否有一些细微差别使 Java 的实现assert比我认为的更有用？在某些情况下，从命令行启用/禁用它的能力真的非常有价值吗？当我设想在生产代码中使用它来代替像这样的语句时，我是否以某种方式误解了它if (listOfStuff == null) barf();？

我只是觉得这里有一些重要的东西我没有得到。

*好吧，从技术上讲，它们实际上是默认关闭的；你必须不遗余力地打开它们。但是，您仍然可以将它们完全淘汰。

首先是调试工具的概念assert对我来说很有意义。

我仍然不同意在生产环境中应该禁用非平凡私有方法的输入检查，因为开发人员认为错误的输入是不可能的。以我的经验，成熟的生产代码是一个疯狂的、庞大的东西，多年来由具有不同技能水平的人针对快速变化的不同理智程度的需求而开发。即使错误的输入确实是不可能的，六个月后的一段草率的维护编码也可以改变这种情况。 gustafc 提供的链接（谢谢！）包括以下示例：

assert interval > 0 && interval <= 1000/MAX_REFRESH_RATE : interval;

在生产中禁用这样一个简单的检查让我觉得愚蠢的乐观。但是，这是编码理念上的差异，而不是损坏的功能。

另外，我绝对可以看到这样的东西的价值：

assert reallyExpensiveSanityCheck(someObject) : someObject;

感谢所有花时间帮助我理解此功能的人；这是非常赞赏。

我正在实现我自己的 ArrayList 用于学校目的，但为了增加趣味性，我正在尝试使用 C# 4.0 代码合同。一切都很好，直到我需要将合同添加到构造函数中。我应该在空参数构造函数中添加 Contract.Ensures() 吗？

我会说是的，每种方法都应该有一个明确定义的合同。另一方面，如果它只是将工作委派给“主要”构造函数，为什么还要这样做呢？从逻辑上讲，我不需要。

我看到在两个构造函数中显式定义合约的唯一一点是，如果将来我们对合约有 Intelisense 支持。如果发生这种情况，明确每种方法具有哪些合同会很有用，就像 Intelisense 中出现的那样。

此外，是否有任何书籍可以更深入地介绍合同设计的原则和用法？一件事是了解如何在语言（在本例中为 C#）中使用合同的语法，另一件事是了解如何以及何时使用它。我阅读了几个教程和 Jon Skeet 的 C# in Depth 文章，但如果可能的话，我想更深入一点。

谢谢

我有一些具有以下逻辑的代码：

理论上，总有一个元素是什么，所以这种方法应该没有问题。无论如何，为了确定，我在方法的末尾添加了一个断言：

问题是这个方法必须返回一些东西，编译器不明白断言会破坏程序的执行。在使用 Contracts 之前，在这种情况下，我曾经抛出一个异常，从而解决了问题。你将如何使用 Contract.Assert() 处理这个问题？在 Contract.Assert() 调用之后返回 null 或 default(element_type) 知道它永远不会被调用并关闭编译器？或者还有其他更优雅的方法吗？

谢谢

我想通过合同跳入编码。我得到了 VS2010（使用 C# 4.0 编译器），但我必须针对 3.5 框架。

合约库中的哪些第 3 方代码具有最类似于 .NET 4.0 的类和接口？

这些天来，我习惯于检查每个功能的每个前提条件，因为我从大学的操作系统编程课程中养成了习惯。

另一方面，在软件工程课程中，我们被教导说，一个共同的前提条件应该只检查一次，例如，如果一个函数委托给另一个函数，第一个函数应该检查它们，但在第二个函数中再次检查它们是多余的。

我确实看到了冗余点，但我当然觉得总是检查它们更安全，而且你不必跟踪它们以前检查的位置。

这里的最佳做法是什么？

最近我和一位同事就单元测试进行了一次有趣的讨论。当您的合同发生变化时，我们正在讨论何时维护单元测试变得不那么高效。

也许任何人都可以启发我如何解决这个问题。让我详细说明：

所以可以说有一个类可以进行一些漂亮的计算。合同说它应该计算一个数字，或者当它由于某种原因失败时返回-1。

我有合同测试来测试它。在我所有的其他测试中，我将这个漂亮的计算器存根。

所以现在我更改了合同，每当它无法计算时，它都会抛出一个 CannotCalculateException。

我的合同测试将失败，我将相应地修复它们。但是，我所有的模拟/存根对象仍将使用旧的合同规则。这些测试会成功，但它们不应该成功！

随之而来的问题是，有了这种对单元测试的信心，对这样的改变有多大信心……单元测试成功了，但是在测试应用程序时会出现错误。需要修复使用此计算器的测试，这会花费时间，甚至可能会被多次存根/嘲笑......

你怎么看这个案子？我从来没有仔细考虑过。在我看来，这些对单元测试的更改是可以接受的。如果我不使用单元测试，我也会在测试阶段（由测试人员）看到此类错误。然而，我没有足够的信心指出什么会花费更多（或更少）时间。

有什么想法吗？

考虑这种不可变类型：

这里需要注意两点：

• 有一个契约不变量，它确保Path财产永远不会null
• 构造函数检查path参数值以尊重先前的合同不变量

在这一点上，一个Setting实例永远不能有一个null Path属性。

现在，看看这种类型：

基本上，它有自己的合同不变量（_path现场），在静态检查期间无法满足（参见上面的评论）。这对我来说听起来有点奇怪，因为它很容易证明：

• settings是不可变的
• settings.Path不能为空（因为 Settings 有对应的契约不变量）
• 所以通过分配settings.Path给_path，_path不能为空

我在这里错过了什么吗？

我正在考虑使用 .NET 4 在 C# 中使用合同设计的个人项目。

我一直在阅读有关微软尝试按合同框架设计的信息：http: //msdn.microsoft.com/en-us/devlabs/dd491992.aspx

但是有很多选择，我很困惑 - 那么哪个是最好的，为什么？各自的优缺点是什么？