通过设计合同和施工 [英] Design by contracts and constructors

问题描述

我实现我自己的ArrayList学校的目的，而是为了调剂事情有点我想用C＃4.0 code合同。一切都很好，直到我需要合同添加到构造函数。我应该补充Contract.Ensures（）中的空参数构造函数？

I am implementing my own ArrayList for school purposes, but to spice up things a bit I'm trying to use C# 4.0 Code Contracts. All was fine until I needed to add Contracts to the constructors. Should I add Contract.Ensures() in the empty parameter constructor?

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

        _array = new T[capacity];
    }

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

我会说是的，每个方法应该有一个明确的合同。在另一方面，何必把它，如果它只是委托工作的主的构造？ Logicwise，我也不会要。

I'd say yes, each method should have a well defined contract. On the other hand, why put it if it's just delegating work to the "main" constructor? Logicwise, I wouldn't need to.

我看到这将会是显式定义的合同在这两个构造有用的唯一的一点是，如果在未来，我们有合同的智能感知支持。请问这种情况发生，它会是明确哪些合同的每一种方法都有，因为这会出现在智能感知是有用的。

The only point I see where it'd be useful to explicitly define the contract in both constructors is if in the future we have Intelisense support for contracts. Would that happen, it'd be useful to be explicit about which contracts each method has, as that'd appear in Intelisense.

此外，还有周围的任何书籍去深一点的设计原理和使用由合同？有一件事情是具有如何使用合同的语言（C＃，在这种情况下）的语法的知识，其他是知道如何以及何时使用它。我看了一些教程和乔恩斯基特的C＃中关于它的深度文章，但我想去深一点，如果可能的。

Also, are there any books around that go a bit deeper on the principles and usage of Design by Contracts? One thing is having knowledge of the syntax of how to use Contracts in a language (C#, in this case), other is knowing how and when to use it. I read several tutorials and Jon Skeet's C# in Depth article about it, but I'd like to go a bit deeper if possible.

感谢

推荐答案

我完全托马斯的答复不同意。只要你在的实施的ArrayList（）作出选择，你应该有一个合同，它是记录这些选择。

I completely disagree with Thomas's answer. As long as you are making choices in the implementation of ArrayList(), you should have a contract for it that document these choices.

在这里，你正在调用与参数32的主要构造有，你可以决定这样做（而不只是关于默认大小的选择），许多其他东西的选择。给人一种合约的ArrayList（）这是几乎相同的的ArrayList（INT）的文档，你决定不做你最可以做的，而不是直接调用它。愚蠢的事情

Here, you are making the choice of calling the main constructor with argument 32. There are many other things that you could have decided to do (not just concerning the choice of the default size). Giving a contract to ArrayList() that is almost identical to that of ArrayList(int) documents that you decided not to do most of the silly things you could have done instead of calling it directly.

答案它调用的主要构造，所以我们的主要构造的合同做的工作，完全忽略了一个事实，该合同是有救你不必看执行。对于基于运行时断言检查验证策略，写作合同即使如此短的构造函数/方法，几乎​​直接调用另一个构造函数/方法的缺点是，你最终检查两次的事情。是的，这似乎是多余的，但运行时断言检查只有一个验证策略，以及DbC的的原则是独立于它。其原理是：如果它可以被调用，它需要一个合同记录它做什么

The answer "it calls the main constructor, so let the main constructor's contract do the job" completely ignores the fact that the contract is there to save you from having to look at the implementation. For a verification strategy based on run-time assertion checking, the disadvantage of writing contracts even for such short constructors/methods that almost directly call another constructor/method is that you end up checking things twice. Yes, it seems redundant, but run-time assertion checking is only one verification strategy, and DbC's principles are independent from it. The principle is: if it can be called, it needs a contract to document what it does.

这篇关于通过设计合同和施工的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！