问题标签 [design-by-contract]

在 asp.net 中有什么必要的 Microsoft.Contracts 命名空间？

我的意思是，在什么情况下我可以写using Microsoft.Contracts;？

以下是实现此目标的典型方法：

我认为这个解决方案很丑陋。您的方法很快就会被检查有效输入参数协定的样板代码填满，从而掩盖了方法的核心。

这是我想要的：

如果这些注释看起来像 JSR 303/Bean Validation Spec，那是因为我借用了它们。不幸的是，它们似乎不是这样工作的。它们用于注释实例变量，然后通过验证器运行对象。

在众多 Java 契约式设计框架中，哪一个提供了与我的“喜欢拥有”示例最接近的功能？抛出的异常应该是运行时异常（如 IllegalArgumentExceptions），因此封装不会被破坏。

我更喜欢 Lisp 变体中的示例（Clojure 或 Scheme 的加分项），因为这是我最熟悉的，但任何关于函数式语言中 DBC 的反馈当然对更大的社区都很有价值。

这是一个明显的方法：

我不喜欢这个实现的是合约逻辑模糊了核心功能；该函数的真正目的在条件检查中丢失了。这与我在这个问题中提出的问题相同。在像 Java 这样的命令式语言中，我可以使用文档中嵌入的注释或元数据/属性将合同从方法实现中移出。

有没有人研究过在 Clojure 中向元数据添加合同？如何使用高阶函数？还有哪些其他选择？

我正在阅读有关 dbc 的信息（http://en.wikipedia.org/wiki/Design_by_contract）有人可以给我一个简单的例子，说明使用与继承相关的类不变量吗？

我一直在阅读按合同设计的帖子和示例，有些东西我似乎无法理解。在我看到的所有示例中，DbC 都用于在后置条件（例如大量银行账户）中测试其自身状态的普通类。

在我看来，大多数时候当你调用一个类的方法时，它会做更多的工作，将方法调用委托给它的外部依赖项。我了解如何在具有特定场景的单元测试中使用依赖反转和模拟对象来检查这一点，这些对象专注于方法的外部行为，但是这如何与 DbC 和后置条件一起工作？

我的第二个问题必须处理理解复杂的后置条件。在我看来，要为许多函数写出一个后置条件，你基本上必须为你的后置条件重新编写函数体，才能知道新状态将是什么。那有什么意义呢？

我真的很喜欢 DbC 的概念，并且我认为它有很大的希望，特别是如果我能够在找到经过验证的合同后弄清楚如何重现某些失败状态。在过去的几个小时里，我一直在阅读一些简洁的东西。Eiffel 中的自动测试生成。我目前正在尝试改进我在 C++ 开发中的流程，但如果我能弄清楚如何不失去我在当前项目中取得的所有基础，我愿意学习新的东西。谢谢。

我最好用一个代码示例来展示我想要完成的事情？

（传递给的字符串Contract.Ensures()当然只是真正的后置条件表达式的占位符。）

我怎样才能做到这一点？在这里有用吗Contract.OldValue<>()？

我有一个项目，客户端使用实体框架，我试图从应用程序的其余部分抽象出生成的类。

一个生成的类是 Category，它说 Type 作为属性。

我创建了一个我希望 Category 实现的接口，如下所示：

我之前在 LINQ to SQL 中做过这个，它工作正常。我在一个单独的文件中创建一个部分类并让它实现接口：

但是，每当我尝试使用 EF 构建查询时，使用 EF 时它都会说它不支持 OfType<>()。

例子：

我在这里做错了什么？

其他需要注意的事项：我在 Silverlight 应用程序中开发它，并且数据上下文实际上是从服务中提取的，因此这里也存在客户端服务器关系。

我们有一个 OO 代码库，在很多情况下hashcode()根本equals()不起作用，主要是因为以下原因：

除非您愿意放弃面向对象抽象的好处，否则无法在保留 equals 契约的同时扩展可实例化类并添加值组件。

这是 Joshua Bloch 的“Effective Java”中的一句话，在 Artima 的一篇很棒的文章中有更多关于这个主题的内容：

http://www.artima.com/lejava/articles/equality.html

我们对此非常满意，这不是这个问题的意义所在。

问题是：看到在某些情况下您无法满足equals()合同是事实，那么自动生成hashcode()和equals()抛出 UnsupportedOperationException 的干净方法是什么？

注释会起作用吗？我正在考虑类似的事情@NotNull：每次@NotNull违反合同都会自动引发异常，除了用@NotNull.

这很方便，因为它是 8 个字符（“@NotNull”），而不是不断重复相同的验证/抛出异常代码。

在我担心的情况下，在每个hashCode()/equals()没有意义的实现中，我们总是重复同样的事情：

然而，这很容易出错：我们可能会错误地忘记剪切/粘贴它，这可能会导致用户误用这些对象（比如试图将它们放入默认的 Java 集合中）。

或者如果不能通过注释来创建这种行为，AOP 会起作用吗？

有趣的是，真正的问题是 Java 层次结构的存在hashCode()和equals()顶部，这在某些情况下根本没有意义。但是那么我们如何干净地处理这个问题呢？

与 C# 中的代码协定相反，在 JML 中，代码协定只是在方法标头中以注释形式使用的文本。那么，将它们作为注释公开不是更好吗？这样，即使在编译信息时，也会保留在 .class 的元数据上，这与注释相反，会被删除。

我错过了什么吗？

出于本次讨论的目的，对象构造函数可能采用两种参数：状态依赖或服务依赖。使用 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”的新型接口。启动类似于接口，但也需要特定的构造函数签名。剩下的我留给学生做练习......