《Design by Contract》介绍

         契约式设计的本意很简单，就是在设计和编码阶段向面向对象程序中加入断言（assertion）。而所谓断言，实际就是必须为真的假设，只 有这些假设为真，程序才可能做到正确无误。契约式设计的主要断言包括先验条件（precondition）、后验条件（postcondition）、以及不变 式（invariant）：

          ● 先验条件针对方法（method），它规定了在调用该方法之前必须为真的条件。

          ● 后验条件也是针对方法，它规定了方法顺利执行完毕之后必须为真的条件。

          ● 不变式针对整个类，它规定了该类任何实例调用任何方法都必须为真的条件。

    断言应使用某中编程语言写在代码里（而不是仅仅通过文档加以声明），只有这样：

         ● 对于程序员而言，它们才有意义，同时能够提供优质的，有用的文档。
 
         ● 能够在运行时对它们进行检测，更好地支持测试和调试工作。

DbC 六大原则

1.区分命令和查询。
   
   查询返回一个结果，但不改变对象的可见性质。
   命令改变对象的状态，但不返回结果。

2.将基本查询同派生查询区分开。
 
   派生查询可以用基本查询来定义。

3.针对每个派生查询，设定一个后验条件，使用一个或多个基本查询的结果来定义它。

   这样一来，只要我们知道基本查询的值，也就能知道派生查询的值。

4.对于每个命令都撰写一个后验条件，规定每个基本查询的值。

  结合原则3。我们现在已经能够知道每个命令的全部可视效果。

5.对于每个查询和命令，采用一个合适的先验条件。

  先验条件限定了客户调用查询和命令的时机。

6.撰写不变式来定义对象的恒定特性。

  类是某种抽象的体现，应当将注意力集中在最重要的属性上，以帮助读者建立关于类抽象的正确概念模型。

DbC 六大准则

1. 在适当的地方添加物理限制。

  尤其是那些需要限制变量不应该为void的地方。

2. 先验条件中尽可能使用高效的查询。

  如果有必要，可以增加高效的派生查询，并在其后验条件中确保其于较低效的基本查询之间的等价关系。

3. 用不变式限定属性。

  如果一个派生查询被实现成一个属性，则应通过类中不变式的断言保证它与其他查询保持一致。

4. 为了支持特性的重定义，用相应的先验条件确保每个后验条件。

  这样就允许在开发子类过程中进行各种不可预见的重定义。

5. 将预期发生的变化和框定规则这两中不同的限制分别放置在不同的类中。

  这使开发者在扩展你的类时享有更多的自由。

6. 若有保密性要求，则违背保密性的查询可以在契约中使用，然后被设为私有属性。

  这里的“设为私有”，是对“在契约中使用了该查询的类”之下的层次而言，至于该类之上的层次，这个查询当然是可使用的。

---

... ...

 如何保证各方恪守职责呢？Eiffel引入了契约（Contract）这个概念。这里的契约与我们通常所说的商业契约很相似，有以下几个特点：

1. 契约关系的双方是平等的，对整个bussiness的顺利进行负有共同责任，没有哪一方可以只享有权利而不承担义务。
2. 契约关系经常是相互的，权利和义务之间往往是互相捆绑在一起的；
3. 执行契约的义务在我，而核查契约的权力在人；
4. 我的义务保障的是你的利益，而你的义务保障的是我的利益；
 
      将契约关系引入到软件开发领域，尤其是面向对象领域之后，在观念上给我们带来了几大冲击：

    一般的观点，在软件体系中，程序库和组件库被类比为server，而使用程序库、组件库的程序被视为client。根据这种C/S关系，我们往往对库程序和组件的质量提出很严苛的要求，强迫它们承担本不应该由它们来承担的责任，而过分纵容client一方，甚至要求库程序去处理明显由于client错误造成的困境。客观上导致程序库和组件库的设计和编写异常困难，而且质量隐患反而更多；同时client一方代码大多松散随意，质量低劣。这种情形，就好像在一个权责不清的企业里，必然会养一批尸位素餐的混混，苦一批任劳任怨，不计得失的老黄牛。引入契约观念之后，这种C/S关系被打破，大家都是平等的，你需要我正确提供服务，那么你必须满足我提出的条件，否则我没有义务“排除万难”地保证完成任务。