如何理解“合同”的含义

Question

我总是看到contract 这个词，它似乎有不同的含义，或者至少在我看来是这样的（我不是以英语为母语的人），所以当我看到“合同”这个词时，我无法确定我应该理解和期待什么。我不知道其他人是否有同样的麻烦，但这让我很烦恼。例如，当我看到“接口”时，我会想到“抽象、依赖注入、继承等”。而且我知道我在寻找什么，并且它正在我的脑海中轻松而轻松地形成。

但是当谈到 contract 这个词时，我无法想象模式、类等。无论它是什么。它是使用interface 或class 或attribute 等形成的吗？

例如，有一个类 here（在 Json.NET 中）谈论名为 IContractResolver 的东西，页面解释了它的用途：

IContractResolver 接口提供了一种自定义方式 JsonSerializer 将 .NET 对象序列化和反序列化为 JSON 无需在您的类上放置属性。

解释很容易理解，但当我看到Contract 时，我不能只是形成想法，我不能说：

“嗯，我期待一些方法可以做到这一点，这样我就可以 覆盖它，然后我在这里/那里使用这个类来改变/实现 一些功能等等。”

这让我很烦恼。我读了一些关于它的文章，但他们在谈论Design by Contract，对于那些对“合同”含义有疑问的人来说，这不是什么有用的东西。

那么有人可以解释一下我应该如何理解这个术语以及当我看到它时我应该期待什么？如果您可以添加一些示例代码以便我将其可视化，那就太好了。

Answer 1

在“契约式设计”中，契约是指库（类、函数）的开发者和消费者之间的协议。

这可能是一个协议，没有人会为某个参数传递null。这可能是一个特定方法总是在不到 200 毫秒内完成的协议。或者在创建对象的线程上引发事件。重要的是有一些充满规则的文档，并且调用者和函数都同意这些规则。

IContractResolver 听起来像是提供了一种数据格式。这不是合同。 （可能有一个合同规定通信的两个端点都将对特定消息使用这种格式，但格式本身并不是一个完整的合同。合同还需要描述何时应该发送每条消息，等等。 )

Answer 2

合同是至少两方之间的协议。在这种情况下，.NET 合约非常有意义。

在按合同设计的上下文中，它是相似的。通过协议设计，您就接口和一些可验证的义务达成一致。

Answer 3

合同是相当宽泛的术语，但有一些特定的含义。因此，要正确理解它，您应该了解上下文。一般定义是（来自here）：

两个或多个人或当事方之间的具有约束力的协议

可以就提供的操作达成一致（部分与协议同义），如here：

服务合同规定了服务支持的操作。

或者必须以什么格式传递数据（here）：

数据合同是服务和客户之间的正式协议

interface 有时也被称为契约——因为它正是它：关于可以调用什么以及如何调用的具有约束力的协议。

数据驱动开发中的契约也是关于可以传递什么数据，可以返回什么数据，以及对象的有效状态是什么的协议。它本质上与第一个引用中的相同：两个不同代码段之间的绑定协议。

因此，如果您不确定上下文，请尝试使用常识。如果您不熟悉上下文，请尝试理解或询问：

• 在这种情况下，合同定义了什么？
• 它是如何定义的？
• 涉及的各方有哪些？

Answer 4

嗯，合同是那些根据上下文具有多种含义的负担词之一。

对我来说，它是两方之间的任何协议，因此它可以是 .NET 接口意义上的接口（即类型），也可以是双方之间交换的一组和序列的消息（即协议）或在您的 JSON 示例中是对象与其持久形式之间的映射。

有趣的是，您更清楚地提到“界面”，因为它不一定如此。我不将它与抽象、依赖注入或继承（尤其是最后一个）相关联，但更松散地与任何类型的协议相关联。也许原因是我从没有内置具有特定含义和关键字的接口的语言开始（例如 C++）。关键是它还取决于上下文。