问题标签 [design-by-contract]

合约编程是 .NET 的现代趋势，但是 PHP 中代码合约的库/框架呢？您如何看待这种范式对 PHP 的适用性？

谷歌搜索“代码合同 php”对我没有任何帮助。

注意：“契约式代码”是指契约式设计，因此它与 .NET 或 PHP 接口无关。

背景：

我们正在为新的嵌入式系统建模固件。目前固件正在 UML 中建模，但不会使用 UML 建模工具的代码生成功能。

目标语言是 C（具体来说是 C99）。

低功耗（即性能、快速执行）和正确性很重要，但正确性是重中之重，高于一切，包括代码大小和执行速度。

在对系统建模时，我们已经确定了一组定义明确的组件。每个组件都有自己的接口，并且许多组件与许多组件交互。

模型中的大多数组件将是实时操作系统 (RTOS) 下的单个任务（线程），尽管有些组件只不过是库。任务完全通过消息传递/队列发布相互通信。与库的交互将以同步函数调用的形式进行。

因为建议/建议可能取决于规模，所以我将提供一些信息。现在可能有大约 12-15 个组件，可能会增长到大约 20 个？不是 100 多个组件。假设平均而言，每个组件与 25% 的其他组件交互。

在组件图中，有端口/连接器用于表示组件之间的接口，即一个组件提供另一个组件所需的东西。到目前为止，一切都很好。

这就是问题所在：在很多情况下，我们不希望“组件 A”能够访问所有“组件 B”的接口，即我们希望将组件 A 限制为组件 B 提供的接口的子集。

问题/问题：

是否有一种系统的、相当直接的方式来执行——最好是在编译时——在组件图上定义的接口契约？

显然，编译时解决方案比运行时解决方案更可取（更早的检测，更好的性能，可能更小的代码）。

例如，假设库组件“B”提供函数 X()、Y() 和 Z()，但我只希望组件“A”能够调用函数 Z()，而不是 X() 和 Y() . 同样，即使组件“A”可能能够通过其消息队列接收和处理大量不同的消息，我们也没有任何组件能够向任何组件发送任何消息。

我能想到的最好办法是为每个组件-组件接口设置不同的头文件，并且只公开（通过头文件）组件允许使用的接口部分。显然这可能会导致大量的头文件。这也意味着组件之间的消息传递不会直接使用 OS API 完成，而是通过函数调用完成，每个函数调用都会构建并发送特定的（允许的）消息。对于同步调用/库，只会公开允许的 API 子集。

对于这个练习，你可以假设人们会表现得很好。 换句话说，不要担心人们直接作弊和剪切和粘贴函数原型，或者包含他们不允许的头文件。如果不允许，他们不会直接从“A”向“B”发布消息，依此类推……

也许有一种方法可以通过编译时断言来强制执行合同。也许有一种更优雅的方法可以在运行时检查/执行它，即使它会产生一些开销。

代码必须干净地编译和 lint，所以“函数原型防火墙”方法是可以的，但似乎可能有一种更惯用的方法来做到这一点。

考虑这两个返回 IEnumerable 的方法：

此代码在调用 IEnumerable 的某些方法时显示了 2 种不同的行为：

当我的代码返回 IEnumerables 时，选择我想要的行为很简单，但是我如何明确定义某个方法获取一个 IEnumerable 作为参数，尽管它调用了多少次“First()”方法，但它创建了一个结果集。

当然，我不想强​​制不必要地创建所有项目，我想将参数定义为 IEnumerable 表示不会从集合中包含或删除任何项目。

编辑：为了清楚起见，问题不在于产量如何工作或为什么 IEnumerable 可以为每次调用返回不同的实例。问题是当我多次调用“First()”或“Take(1)”等方法时，如何指定参数应该是“仅搜索”集合，该集合返回 MyClass 的相同实例。

有任何想法吗？

提前致谢！

合同设计似乎对表达规范有限制。例如，我试图用合同来表达 Stack FILO 属性，但没有得到任何想法。有人可以帮忙吗？

我认为根本原因是前置条件/​​后置条件/不变量是没有副作用的断言。它导致了对 FILO 属性的检查，这是一种不容易甚至不可能的副作用。

前几天我看到了一个 Code Contracts 的演示，并决定在一个小测试项目中试一试。

在向类添加“使用 System.Diagnostics.Contracts”语句后，我可以适当地设置我的代码合同代码，但合同似乎没有得到执行。

我在项目属性屏幕上看不到“代码合同”选项卡是否有原因？

下面是一个非常简单的例子。当我打开静态分析警告时，我仍然收到 警告 CodeContracts: Ensure unproven: Contract.Result() != string.Empty

在线上

return string.Format("{0}, {1}", movie.Title, movie.Description);

请看我下面的代码

有任何想法吗？

我知道 C# 4.0 具有Code Contract可用于实现后置条件和前置条件的特性。但我只想使用 C# 3.0 来实现它。我正在尝试在我的工作中使用此功能。是否可以attributes用来实现后置条件和前置条件？

有什么建议吗？

谢谢。

这实际上是一个设计问题。我想知道携带 JSON 有效负载的 Spring3.0 REST Web 服务是否提供某种类似于遵循契约优先设计的传统 Web 服务的数据契约。我知道 JSON 具有类似于 XSD 的模式，但它在哪里适合春天？背景：我考虑使用 json 作为客户端服务器架构项目的有效负载，其中客户端是基于 .NET 的应用程序，数据合约应该提供一种处理客户端多个版本的方法。客户端应该能够将数据结构发布到服务器。或者也许我应该采用无模式的方法并使用类似于 XmlAnyElement 的“简单数据绑定”？

是否有任何已建立的模式来检查 C++ 中的类不变量？

理想情况下，将在每个公共成员函数的开始和结束时自动检查不变量。据我所知，带有类的 C 语言提供了特殊before的after成员函数，但不幸的是，当时契约式设计并不是很流行，除了 Bjarne 之外没有人使用该功能，因此他将其删除。

当然，check_invariants()在每个公共成员函数的开头和结尾手动插入调用既繁琐又容易出错。由于 RAII 是处理异常的首选武器，因此我提出了以下方案，将不变性检查器定义为第一个局部变量，并且该不变性检查器在构造和销毁时检查不变量：

问题#0：我想没有办法声明一个未命名的局部变量？:)

我们仍然必须check_invariants()在构造函数的末尾和析构函数Foo的开头手动调用。Foo但是，许多构造函数体和析构函数体是空的。在那种情况下，我们可以使用 aninvariants_checker作为最后一个成员吗？

问题 #1：即使对象仍在构造中，传递this给invariants_checker立即通过该指针调用的构造函数是否有效？check_invariantsFoo

问题 #2：您认为这种方法还有其他问题吗？你能改进它吗？

问题 3：这种方法是新的还是众所周知的？有没有更好的解决方案？

我正在尝试将一些按合同设计的技术融入我的编码风格。后置条件在我看来很像嵌入式单元测试，我想知道我的想法是在正确的轨道上还是偏离了基础。

维基百科将后置条件定义为“一个条件或谓词，在执行某些代码部分或正式规范中的操作后必须始终为真。后置条件有时使用代码本身中的断言进行测试”。

这与您在直接验证状态（不使用模拟）的单元测试中所做的不太相似吗？

如果是这样的话：

1）通过使用后置条件，我现在不是在我的生产代码中嵌入测试代码吗，这不是不被接受吗？

2) 使用后置条件是否应该改变我的单元测试的结构？我的第一个想法是断言逻辑从测试转移到后置条件。也就是说，测试将使用相同的输入，我仍在测试我之前测试的所有内容，但现在我不是在单元测试中做出断言，而是对后置条件是否通过进行简单的二进制断言。

3）我的第二个想法是后置条件代码可能具有控制流，因此不适用于测试代码，测试代码应该简单并避免控制流。但是，如果我测试后置条件，我可以在单元测试中依赖它们吗？

4) 测试后置条件似乎很困难，因为如果我正确理解它们，它们基本上通过或失败，您将不得不重复后置条件本身的逻辑以检查它是否做了正确的事情。那么，如何测试后置条件呢？您是否通过不在单元测试中使用它们并确保您的单元测试和后置条件一起通过或失败来检查它们？

5) 我的单元测试有时会验证某个方法是否会导致协作者的状态发生变化。在标准实践中，后置条件是涵盖协作者状态还是仅涵盖它们所定义的类的状态？