c# - 由契约(Contract)和 build 者设计

Question

我正在为学校目的实现我自己的 ArrayList，但为了让事情更有趣，我正在尝试使用 C# 4.0 代码契约。一切都很好，直到我需要将 Contracts 添加到构造函数中。我应该在空参数构造函数中添加 Contract.Ensures() 吗？

    public ArrayList(int capacity) {
        Contract.Requires(capacity > 0);
        Contract.Ensures(Size == capacity);

        _array = new T[capacity];
    }

    public ArrayList() : this(32) {
        Contract.Ensures(Size == 32);
    }

我会说是的，每个方法都应该有一个定义明确的契约。另一方面，如果它只是将工作委托(delegate)给“主”构造函数，为什么要放它呢？从逻辑上讲，我不需要。

我认为在两个构造函数中显式定义契约(Contract)有用的唯一一点是，如果将来我们对契约(Contract)有 Intelisense 支持。如果发生这种情况，明确说明每种方法具有哪些契约(Contract)会很有用，因为它会出现在 Intelisense 中。

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

谢谢

Answer 1

我完全不同意 Thomas 的回答。只要您在 ArrayList() 的实现中做出选择，您就应该有一个记录这些选择的契约(Contract)。

在这里，您正在选择使用参数 32 调用主构造函数。您可以决定做很多其他事情(不仅仅是关于默认大小的选择)。为 ArrayList() 提供一个几乎与 ArrayList(int) 相同的契约(Contract)，表明你决定不做大部分你本可以做的傻事，而不是直接调用它。

答案“它调用主构造函数，所以让主构造函数的契约来完成这项工作”完全忽略了一个事实，即契约的存在是为了让您不必查看实现。对于基于运行时断言检查的验证策略，即使是为几乎直接调用另一个构造函数/方法的如此短的构造函数/方法编写契约的缺点是您最终会检查两次。是的，这似乎是多余的，但是运行时断言检查只是一种验证策略，DbC 的原则是独立于它的。原则是:如果它可以被调用，它需要一个合约来记录它做了什么。