问题标签 [code-contracts]

好的，这可能有点 hack，但请耐心等待:) 背景是我厌倦了一些 if 语句会弄乱整个方法的缩进的方法，例如：

所以我在想，如果我能做这样的事情不是很好：

这种情况可能会以某种形式被代码合同所涵盖，如果是这样，请纠正我:)

这个想法是，如果该语句的计算结果不为 true，它将返回 null。如果该方法没有返回类型，它只会是： Require(IsOpenFilter(inputStr));

所以我想有两个问题，这可以以某种方式完成吗？我对如何通过调用方法进行有条件的返回感到困惑。

另一个问题是，这是个好主意吗？像这样对语言进行猴子补丁有点奇怪，但我更喜欢代码的读取方式。如果可以将其放入方法上方的属性中，我会更干净： [Require(IsOpenFilter(inputStr))]

.NET 4 引入了代码契约作为一项新功能。我想使用 CC，但提供仍然可以在 3.5 SP1 中运行的文件。那可能吗？我可以只使用部分新功能吗？显然可以让 CC 只进行静态检查而不包含在二进制文件中，对吗？

我知道 CC 作为单独的模块可用于 3.5，如果我不能使用 CC 的 4 版本，这是一个可行的解决方法吗？功能集有区别吗？

我创建了一些类库，其中一些被世界各地的其他人使用，现在我开始使用 Visual Studio 2010 我想知道切换到使用代码合同而不是常规的旧 - 对我来说是多么好的主意风格的 if 语句。

IE。而不是这个：

用这个：

我问的原因是我知道静态检查器对我不可用，所以我对我做出的一些假设有点紧张，编译器无法验证。这可能会导致类库不为下载它的人编译，当他们有静态检查器时。再加上我什至无法重现该问题，修复起来会很烦人，而且我认为，如果它看起来甚至没有从盒子。

所以我有几个问题：

• 如果您有权访问静态检查器，它是否默认打开？或者是否有我需要在类库中打开的设置（因为我没有静态检查器，所以我不会）
• 我的担心是没有根据的吗？上述情况是一个真正的问题吗？

任何的建议都受欢迎。

编辑：让我澄清一下我的意思。

假设我在一个类中有以下方法：

然后我有这个代码：

现在，在这里，IoC 开始了，解决了一些“随机”类，为我提供了一个文件名。假设对于这个库，我不可能取回一个不会给我一个非空文件名的类，但是，由于 IoC 调用的性质，静态分析无法验证这一点，因此可能假设一个可能的值可能为空。

LogToFile因此，静态分析可能会得出结论，即存在使用参数调用方法的风险null，因此无法构建。

我知道我可以在代码中添加假设，说编译器应该接受它，因为fileName我从那个方法得到的永远不会为空，但是如果我没有静态分析器（VS2010 Professional），上面代码会为我编译，因此我可能会将它作为一个沉睡的错误留给拥有 Ultimate 的人来查找。换句话说，不会有编译时警告说明这里可能有问题，所以我可能会按原样发布库。

那么这是一个真实的场景和问题吗？

System.Diagnostics.Contracts.ContractException 在我的测试项目中不可访问。请注意，这段代码纯粹是我自己在弄乱我闪亮的 Visual Studio 新副本，但我想知道我做错了什么。

我用的是专业版的VS，所以没有静态检查。为了仍然使用代码契约（我喜欢），我认为我的方法可以工作的唯一方法是捕获运行时抛出的异常，但我认为这不可能。

测试方法

方法

错误

编辑

经过一番思考，我得出了评论中讨论的结论，以及以下内容。给定一个方法，如果它有一个可以用代码合同形式表达的要求，我会这样写测试。

这将确保合约是代码的一部分，并且不会被删除。然而，这将要求代码合同实际抛出指定的异常。然而，在某些情况下，这不是必需的。

出于本次讨论的目的，对象构造函数可能采用两种参数：状态依赖或服务依赖。使用 IOC 容器提供服务依赖项很容易：DI 接管。但相比之下，状态依赖通常只有客户端知道。即对象请求者。

事实证明，让客户端通过 IOC 容器提供状态参数是非常痛苦的。我将展示几种不同的方法来做到这一点，所有这些方法都有很大的问题，并询问社区是否还有我遗漏的其他选择。让我们开始：

在我将 IOC 容器添加到我的项目代码之前，我从一个这样的类开始：

我决定向 Foobar 类添加一个 Logger 服务依赖关系，也许我会通过 DI 提供：

但后来我也被告知我需要让类 Foobar 本身“可交换”。也就是说，我需要对 Foobar 实例进行服务定位。我在组合中添加了一个新界面：

当我进行服务定位器调用时，它将为我提供 ILogger 服务依赖项。不幸的是，状态依赖项 Alpha 和 Omega 并非如此。一些容器提供了一种语法来解决这个问题：

我喜欢这个功能，但我不喜欢它是无类型的，并且对开发人员来说必须传递哪些参数（通过智能感知等）并不明显。所以我看另一个解决方案：

以上解决了类型安全和智能感知问题，但它（1）强制 Foobar 类通过服务定位器而不是 DI 获取 ILogger 并且（2）它需要我制作一堆样板（XXXFactory，IXXXFactory）对于我可能使用的各种 Foobar 实现。如果我决定采用纯粹的服务定位器方法，它可能不是问题。但我仍然无法忍受完成这项工作所需的所有样板。

所以我尝试了另一种容器提供的支持：

通过这种方法，我已经恢复了一半的智能。但是我必须等到运行时才能检测到我可能忘记提供“FoobarParams”参数的错误。

所以让我们尝试一种新方法：

我实际上不介意我使用具体的“Foobar”类来创建 IFoobar。它代表了一个我不希望在我的代码中改变的基本概念。我也不介意静态“创建”中缺乏类型安全，因为它现在被封装了。我的智能感知也在工作！如果它们不适用（Unity 2.0 行为），以这种方式创建的任何具体实例都将忽略提供的状态参数。也许一个不同的具体实现“FooFoobar”可能有一个正式的 arg 名称不匹配，但我仍然很满意。

但这种方法的一个大问题是它只能在 Unity 2.0 中有效（结构图中的不匹配参数会引发异常）。所以只有我留在 Unity 才好。问题是，我开始越来越喜欢 Structure Map。所以现在我进入另一个选择：

现在有了这个，我对其他方法有了一个很好的折衷：（1）我的论点是类型安全/智能感知的（2）我可以选择通过 DI（如上所示）或服务定位器获取 ILogger，（ 3）不需要制作一个或多个单独的具体 FoobarFactory 类（与前面冗长的“样板”示例代码对比），并且（4）它合理地维护了“使接口易于正确使用，难以正确使用”的原则使用不当。” 至少可以说它并不比前面讨论的替代方案差。

一个接受障碍仍然存在：我还想申请“按合同设计”。

我提供的每个示例都有意支持构造函数注入（用于状态依赖项），因为我想保留最常用的“不变”支持。即，不变量在构造函数完成时建立。

在上面的示例中，当对象构造完成时，不变量没有建立。只要我在做本土的“合同设计”，我就可以告诉开发人员在调用 Initialize(...) 方法之前不要测试不变量。

但更重要的是，当 .net 4.0 出来时，我想使用它的“代码契约”支持按契约进行设计。根据我的阅读，它与最后一种方法不兼容。

诅咒！

当然，我也想到我的整个哲学都是错误的。也许有人告诉我，通过服务定位器召唤一个 Foobar : IFoobar 意味着它是一个服务 - 服务只有其他服务依赖关系，它们没有状态依赖关系（例如这些示例中的 Alpha 和 Omega）。我也乐于聆听此类哲学问题，但我也想知道阅读哪些半权威性参考资料会引导我走上这条思想道路。

所以现在我把它转向社区。我应该考虑什么方法我还没有？我必须真的相信我已经用尽了我的选择吗？

ps 这种问题，连同其他问题，让我相信整个 IOC Container 的想法，至少在 .net 中，还为时过早。它让我想起了人们会站在他们的头上让“C”语言感觉面向对象的日子（添加奇怪的宏等）。我们应该寻找的是 IOC Containers 的 CLR 和语言支持。例如，想象一种称为“initiate”的新型接口。启动类似于接口，但也需要特定的构造函数签名。剩下的我留给学生做练习......

我正在与CodeContracts 静态分析工具争论。

我的代码：

（ASCII 版本）

该工具告诉我这instance.bar可能是一个空引用。我相信相反。

谁是对的？我怎样才能证明它是错的？

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

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

我在 C# 4.0 中使用代码合同。我正在应用通常的静态方法链接来模拟可选参数（我知道 C# 4.0 支持可选参数，但我真的不想使用它们）。

问题是，如果我调用该Init(string , string[])方法，我的合同要求会执行两次（或者可能是我要实现的链式重载的数量）——从下面的示例源代码中可以明显看出这一点。这可能很昂贵，尤其是由于像File.Exists我使用的相对昂贵的要求。

但是，如果我从该方法中删除了要求，则静态检查器会抱怨Init(string, string[], string)未满足重载的要求。我认为静态检查器不理解Init(string, string[], string)重载的要求也隐含地适用于该Init(string, string[])方法；可以从代码 IMO 中完全扣除的东西。

这是我想达到的情况：

所以，我的问题是：有没有办法让Init(string, string[], string)隐式应用的要求Init(string, string[])自动适用？

更新

我ForAll以错误的方式使用该方法：它旨在在需求或类似内容中使用，如下所示：

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

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

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

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

谢谢

我有一个 C# 商业应用程序，带有单元测试。我可以通过使用 NModel 或 Spec Explorer 来提高可靠性并减少测试时间和费用吗？或者，如果我用 F#（甚至 Haskell）重写它，我会看到什么样的（如果有的话）可靠性增加？

代码合同？阿斯麦?

我意识到这是主观的，可能是有争议的，所以如果可能的话，请用数据来支持你的答案。:) 或者也许是一个可行的例子，例如 Eric Evans Cargo Shipping System？

如果我们考虑

单元测试是具体的强定理，对特定的“有趣的实例”进行准静态检查，类型是一般但弱的定理（通常静态检查），合同是一般和强定理，动态检查发生在常规程序运行。（来自 B. Pierce 的认为有害的类型），

这些其他工具在哪里适合？

我们可以使用 Java PathFinder、Scala 等为 Java 提出类似的问题。