。它不但可以使开发人员的思维更清晰而且对于提高程序性能很有帮助。值得一提的是它对于并行程序设计也有莫大的益处。我们先看一段很简单的未使用契约式编程的代码示例。// .NET 代码示例 public class RationalNumber { private int numberator; private int denominator; public RationalNumber(int numberator, int denominator) { this.numberator numberator; this.denominator denominator; } public int Denominator { get { return this.denominator; } } }上述代码表示一个在 32 位有符号整型范围内的有理数。数学上有理数是一个整数 a 和一个非零整数 b 的比通常写作 a/b故又称作分数(题外话有理数这个翻译真是够奇怪)。由此我们知道有理数的分母不能为 0 。所以上述代码示例的构造函数还需要写些防御性代码。通常 .NET 开发人员会这样写// .NET 代码示例 public class RationalNumber { private int numberator; private int denominator; public RationalNumber(int numberator, int denominator) { if (denominator 0) throw new ArgumentException(The second argument can not be zero.); this.numberator numberator; this.denominator denominator; } public int Denominator { get { return this.denominator; } } }下面我们来看一下使用契约式编程的 .NET 4.0 代码示例。为了更加方便的说明博主在整个示例上都加了契约但此示例并非一定都加这些契约。// .NET 代码示例 public class RationalNumber { private int numberator; private int denominator; public RationalNumber(int numberator, int denominator) { Contract.Requires(denominator ! 0, The second argument can not be zero.); this.numberator numberator; this.denominator denominator; } public int Denominator { get { Contract.Ensures(Contract.Resultint() ! 0); return this.denominator; } } [ContractInvariantMethod] protected void ObjectInvariant() { Contract.Invariant(this.denominator ! 0); } }详细的解释稍后再说。按理既然契约式编程有那么多好处那在 C/C 世界应该很流行才对。为什么很少看到关于契约式编程的讨论呢看一下 C 的契约式编程示例就知道了。下面是 C 代码示例//typedef long int32_t; #include stdint.h template inline void CheckInvariant(T argument) { #ifdef CONTRACT_FULL argument.Invariant(); #endif } public class RationalNumber { private: int32_t numberator; int32_t denominator; public: RationalNumber(int32_t numberator, int32_t denominator) { #ifdef CONTRACT_FULL ASSERT(denominator ! 0); CheckInvaraint(*this); #endif this.numberator numberator; this.denominator denominator; #ifdef CONTRACT_FULL CheckInvaraint(*this); #endif } public: int32_t GetDenominator() { #ifdef CONTRACT_FULL // C Developers like to use struct type. class Contract { int32_t Result; Contract() { } ~Contract() { } } #endif #ifdef CONTRACT_FULL Contract contract new Contract(); contract.Result denominator; CheckInvairant(*this); #endif return this.denominator; #ifdef CONTRACT_FULL CheckInvaraint(*this); #endif } protected: #ifdef CONTRACT_FULL virtual void Invariant() { this.denominator ! 0; } #endif }Woo..., 上述代码充斥了大量的宏和条件编译。对于习惯了 C# 优雅语法的 .NET 开发人员来说它们是如此丑陋。更重要的是契约式编程在 C 世界并未被标准化因此项目之间的定义和修改各不一样给代码造成很大混乱。这正是很少在实际中看到契约式编程应用的原因。但是在 .NET 4.0 中契约式编程变得简单优雅起来。.NET 4.0 提供了契约式编程库。实际上.NET 4.0 仅仅是针对 C 宏和条件编译的再次抽象和封装。它完全基于 CONTRACTS_FULL CONTRACTS_PRECONDITIONS Symbol 和 System.Diagnostics.Debug.Assert 方法、System.Environment.FastFail 方法的封装。那么何谓契约式编程何谓契约式编程契约是减少大型项目成本的突破性技术。它一般由 Precondition(前置条件) Postcondition(后置条件) 和 Invariant(不变量) 等概念组成。.NET 4.0 除上述概念之外还增加了 Assert(断言)Assume(假设) 概念。这可以由枚举 ContractFailureKind 类型一窥端倪。契约的思想很简单。它只是一组结果为真的表达式。如若不然契约就被违反。那按照定义程序中就存在纰漏。契约构成了程序规格说明的一部分只不过该说明从文档挪到了代码中。开发人员都知道文档通常不完整、过时甚至不存在。将契约挪移到代码中就使得程序可以被验证。正如前所述.NET 4.0 对宏和条件编译进行抽象封装。这些成果大多集中在 System.Diagnostics.Contracts.Contract 静态类中。该类中的大多数成员都是条件编译。这样我们就不用再使用 #ifdef 和定义 CONTRACTS_FULL 之类的标记。更重要的是这些行为被标准化可以在多个项目中统一使用并根据情况是否生成带有契约的程序集。1. AssertAssert(断言)是最基本的契约。.NET 4.0 使用 Contract.Assert() 方法来特指断言。它用来表示程序点必须保持的一个契约。Contract.Assert(this.privateField 0); Contract.Assert(this.x 3, Why isn’t the value of x 3?);断言有两个重载方法首参数都是一个布尔表达式第二个方法的第二个参数表示违反契约时的异常信息。当断言运行时失败.NET CLR 仅仅调用 Debug.Assert 方法。成功时则什么也不做。2. Assume.NET 4.0 使用 Contract.Assume() 方法表示 Assume(假设) 契约。Contract.Assume(this.privateField 0); Contract.Assume(this.x 3, Static checker assumed this);Assume 契约在运行时检测的行为与 Assert(断言) 契约完全一致。但对于静态验证来说Assume 契约仅仅验证已添加的事实。由于诸多限制静态验证并不能保证该契约。或许最好先使用 Assert 契约然后在验证代码时按需修改。当 Assume 契约运行时失败时 .NET CLR 会调用 Debug.Assert(false)。同样成功时什么也不做。3. Preconditions.NET 4.0 使用 Contract.Requires() 方法表示 Preconditions(前置条件) 契约。它表示方法被调用时方法状态的契约通常被用来做参数验证。所有 Preconditions 契约相关成员至少方法本身可以访问。Contract.Requires(x ! null);Preconditions 契约的运行时行为依赖于几个因素。如果只隐式定义了 CONTRACTS PRECONDITIONS 标记而没有定义 CONTRACTS_FULL 标记那么只会进行检测 Preconditions 契约而不会检测任何 Postconditions 和 Invariants 契约。假如违反了 Preconditions 契约那么 CLR 会调用 Debug.Assert(false) 和 Environment.FastFail 方法。假如想保证 Preconditions 契约在任何编译中都发挥作用可以使用下面这个方法Contract.RequiresAlways(x ! null);为了保持向后兼容性当已存在的代码不允许被修改时我们需要抛出指定的精确异常。但是在 Preconditions 契约中有一些格式上的限定。如下代码所示if (x null) throw new ArgumentException(The argument can not be null.); Contract.EndContractBlock(); // 前面所有的 if 检测语句皆是 Preconditions 契约这种 Preconditions 契约的格式严格受限它必须严格按照上述代码示例格式。而且不能有 else 从句。此外then 从句也只能有单个 throw 语句。最后必须使用 Contract.EndContractBlock() 方法来标记 Preconditions 契约结束。看到这里是不是觉得大多数参数验证都可以被 Preconditions 契约替代没有错事实的确如此。这样这些防御性代码完全可以在 Release 被去掉从而不用做那些冗余的代码检测从而提高程序性能。但在面向验证客户输入此类情境下防御性代码仍有必要。再就是Microsoft 为了保持兼容性并没有用 Preconditions 契约代替异常。4. PostconditionsPostconditions 契约表示方法终止时的状态。它跟 Preconditions 契约的运行时行为完全一致。但与 Preconditions 契约不同Postconditions 契约相关的成员有着更少的可见性。客户程序或许不会理解或使用 Postconditions 契约表示的信息但这并不影响客户程序正确使用 API 。对于 Preconditions 契约来说它则对客户程序有副作用不能保证客户程序不违反 Preconditions 契约。A. 标准 Postconditions 契约用法.NET 4.0 使用 Contract.Ensures() 方法表示标准 Postconditions 契约用法。它表示方法正常终止时必须保持的契约。Contract.Ensures(this.F 0);B. 特殊 Postconditions 契约用法当从方法体内抛出一个特定异常时通常情况下 .NET CLR 会从方法体内抛出异常的位置直接跳出从而辗转堆栈进行异常处理。假如我们需要在异常抛出时还要进行 Postconditions 契约验证我们可以如下使用Contract.EnsuresOnThrowsT(this.F 0);其中小括号内的参数表示当异常从方法内抛出时必须保持的契约而泛型参数表示异常发生时抛出的异常类型。举例来说当我们把 T 用 Exception 表示时无论什么类型的异常被抛出都能保证 Postconditions 契约。哪怕这个异常是堆栈溢出或任何不能控制的异常。强烈推荐当异常是被调用 API 一部分时使用 Contract.EnsuresOnThrowsT() 方法。C. Postconditions 契约内的特殊方法以下要讲的这几个特殊方法仅限使用在 Postconditions 契约内。方法返回值在 Postconditions 契约内可以通过 Contract.ResultT() 方法表示其中 T 表示方法返回类型。当编译器不能推导出 T 类型时我们必须显式指出。比如C# 编译器就不能推导出方法参数类型。Contract.Ensures(0 Contract.Resultint());假如方法返回 void 则不必在 Postconditions 契约内使用 Contract.ResultT() 。前值(旧值)在 Postconditions 契约内通过 Contract.OldValueT(e) 表示旧有值其中 T 是 e 的类型。当编译器能够推导 T 类型时可以忽略。此外 e 和旧有表达式出现上下文有一些限制。旧有表达式只能出现在 Postconditions 契约内。旧有表达式不能包含另一个旧有表达式。一个很重要的原则就是旧有表达式只能引用方法已经存在的那些旧值。比如只要方法 Preconditions 契约持有它必定能被计算。下面是这个原则的一些示例方法的旧有状态必定存在其值。比如 Preconditions 契约暗含 xs ! null xs 当然可以被计算。但是假如 Preconditions 契约为 xs ! null || E(E 为任意表达式)那么 xs 就有可能不能被计算。Contract.OldValue(xs.Length); // 很可能错误方法返回值不能被旧有表达式引用。Contract.OldValue(Contract.Resultint() x); // 错误out 参数也不能被旧有表达式引用。如果某些标记的方法依赖方法返回值那么这些方法也不能被旧有表达式引用。Contract.ForAll(0, Contract.Resultint(), i Contract.OldValue(xs[i]) 3); // 错误旧有表达式不能在 Contract.ForAll() 和 Contract.Exists() 方法内引用匿名委托参数除非旧有表达式被用作索引器或方法调用参数。Contract.ForAll(0, xs.Length, i Contract.OldValue(xs[i]) 3); // OKContract.ForAll(0, xs.Length, i Contract.OldValue(i) 3); // 错误如果旧有表达式依赖于匿名委托的参数那么旧有表达式不能在匿名委托的方法体内。除非匿名委托是 Contract.ForAll() 和 Contract.Exists() 方法的参数。Foo( ... (T t) Contract.OldValue(... t ...) ... ); // 错误D. out 参数因为契约出现在方法体前面所以大多数编译器不允许在 Postconditions 契约内引用 out 参数。为了绕开这个问题.NET 契约库提供了 Contract.ValueAtReturnT(out T t) 方法。public void OutParam(out int x) { Contract.Ensures(Contract.ValueAtReturn(out x) 3); x 3; }跟 OldValue 一样当编译器能推导出类型时泛型参数可以被忽略。该方法只能出现在 Postconditions 契约。方法参数必须是 out 参数且不允许使用表达式。需要注意的是.NET 目前的工具不能检测确保 out 参数是否正确初始化而不管它是否在 Postconditions 契约内。因此 x 3 语句假如被赋予其他值时编译器并不能发现错误。但是当编译 Release 版本时编译器将发现该问题。5. Object Invariants对象不变量表示无论对象是否对客户程序可见类的每一个实例都应该保持的契约。它表示对象处于一个“良好”状态。在 .NET 4.0 中对象的所有不变量都应当放入一个受保护的返回 void 的实例方法中。同时用[ContractInvariantMethod]特性标记该方法。此外该方法体内在调用一系列 Contract.Invariant() 方法后不能再有其他代码。通常我们会把该方法命名为 ObjectInvariant 。[ContractInvariantMethod] protected void ObjectInvariant() { Contract.Invariant(this.y 0); Contract.Invariant(this.x this.y); }同样Object Invariants 契约的运行时行为和 Preconditions 契约、Postconditions 契约行为一致。CLR 运行时会在每个公共方法末端检测 Object Invariants 契约但不会检测对象终结器或任何实现 System.IDisposable 接口的方法。6. Contract 静态类中的其他特殊方法.NET 4.0 契约库中的 Contract 静态类还提供了几个特殊的方法。它们分别是A. ForAllContract.ForAll() 方法有两个重载。第一个重载有两个参数一个集合和一个谓词。谓词表示返回布尔值的一元方法且该谓词应用于集合中的每一个元素。任何一个元素让谓词返回 false ForAll 停止迭代并返回 false 。否则 ForAll 返回 true 。下面是一个数组内所有元素都不能为 null 的契约示例public T[] FooT(T[] array) { Contract.Requires(Contract.ForAll(array, (T x) x ! null)); }B. Exists它和 ForAll 方法差不多。7. 接口契约因为 C#/VB 编译器不允许接口内的方法带有实现代码所以我们如果想在接口中实现契约需要创建一个帮助类。接口和契约帮助类通过一对特性来链接。如下所示[ContractClass(typeof(IFooContract))] interface IFoo { int Count { get; } void Put(int value); } [ContractClassFor(typeof(IFoo))] sealed class IFooContract : IFoo { int IFoo.Count { get { Contract.Ensures(Contract.Resultint() 0); return default(int); // dummy return } } void IFoo.Put(int value) { Contract.Requires(value 0); } }.NET 需要显式如上述声明从而把接口和接口方法相关联起来。注意我们不得不产生一个哑元返回值。最简单的方式就是返回 default(T)不要使用 Contract.ResultT 。由于 .NET 要求显式实现接口方法所以在契约内引用相同接口的其他方法就显得很笨拙。由此.NET 允许在契约方法之前使用一个局部变量引用接口类型。如下所示[ContractClassFor(typeof(IFoo))] sealed class IFooContract : IFoo { int IFoo.Count { get { Contract.Ensures(Contract.Resultint() 0); return default(int); // dummy return } } void IFoo.Put(int value) { IFoo iFoo this; Contract.Requires(value 0); Contract.Requires(iFoo.Count 10); // 否则的话就需要强制转型 ((IFoo)this).Count } }8. 抽象方法契约同接口类似.NET 中抽象类中的抽象方法也不能包含方法体。所以同接口契约一样需要帮助类来完成契约。代码示例不再给出。9. 契约方法重载所有的契约方法都有一个带有 string 类型参数的重载版本。如下所示Contract.Requires(obj ! null, if obj is null, then missiles are fired!);这样当契约被违反时.NET 可以在运行时提供一个信息提示。目前该字符串只能是编译时常量。但是将来 .NET 可能会改变字符串可以运行时被计算。但是如果是字符串常量静态诊断工具可以选择显示它。10. 契约特性A. ContractClass 和 ContractClassFor这两个特性我们已经在接口契约和抽象方法契约里看到了。ContractClass 特性用于添加到接口或抽象类型上但是指向的却是实现该类型的帮助类。ContractClassFor 特性用来添加到帮助类上指向我们需要契约验证的接口或抽象类型。B. ContractInvariantMethod这个特性用来标记表示对象不变量的方法。C. PurePure 特性只声明在那些没有副作用的方法调用者上。.NET 现存的一些委托可以被认为如此比如 System.PredicateT 和 System.ComparisonT。D. RuntimeContracts这是个程序集级别的特性(具体如何俺也不太清楚)。E. ContractPublicPropertyName这个特性用在字段上。它被用在方法契约中且该方法相对于字段来说更具可见性。比如私有字段和公共方法。如下所示[ContractPublicPropertyName(PublicProperty)] private int field; public int PublicProperty { get { ... } }F. ContractVerification这个特性用来假设程序集、类型、成员是否可被验证执行。我们可以使用 [ContractVerification(false)] 来显式标记程序集、类型、成员不被验证执行。.NET 契约库目前的缺陷接下来讲一讲 .NET 契约库目前所存在的一些问题。值类型中的不变量是被忽略的不发挥作用。