首页 > 代码库 > 契约式设计(DbC)感想(二)

契约式设计(DbC)感想(二)

契约式设计6大原则的理解

在《Design by Contract原则与实践》中,作者定义了契约式设计的6大原则:

  1. 区分命令和查询;
  2. 将基本查询和派生查询区分开;
  3. 针对每个派生查询,设定一个后验条件,使用一个或多个基本查询的结果来定义它;
  4. 对于每个命令都撰写一个后验条件,规定每个基本查询的值;
  5. 对于每个查询和命令,采用一个合适的先验条件;
  6. 撰写不变式来定义对象的恒定特性。

前面5个针对operation层面而言,不论是面向对象也好,面向过程也好,函数式也好,都可以适用。最后1个针对data层面而言,特别适用于面向对象等有着数据的组合的模式。细分下去,前面2点是对于operation对对象状态的改变的分别,而3、4两点是后验条件的原则,第5点是先验条件的原则。

1、区分命令和查询

  根据operation是否改变对象的状态,将operation分为命令和查询两类,这个应该直接在命名上就体现出来,比如查询应该使用getXXX等,一眼看到就知道这个是查询,不改变对象状态,那个是命令,会改变对象状态。这个分类除了让我们能一眼就看出operation的特点之外,还是整个DbC在Operation组合的正则性的基础。如果划分错误,则可能破坏Operation组合的正则性(比如将一个命令操作当成查询操作来处理)

2、将基本查询和派生查询区分开

  对查询进行细分,有的查询可以有其它查询组合,有些是不能由其它查询组合而得的,前者为派生查询,后者为基本查询。

  对于基本查询,它是不需要后验条件的,是默认 assert(postcondition) == true的,因为它是原始的,primitive查询,而派生查询是由基本查询组合而成,这中间涉及到了作者的逻辑,需要一个后验条件,以确保这个逻辑是正确的。

  因为基本查询是确定满足后验条件的,所以,如果除了基本查询之外的所有其他operation的后验条件最终都由基本查询构成,那么久保证这些operation的后验条件的正确性和正当性。引申出来就是原则3和原则4:

  PostCondition(PrimitiveQuery) =

    ^ Assert(postcondition) == true

  PostCondition(ComposedQuery)= PrimitiveQuery{1..n}

  PostCondition(Command)=PrimitiveQuery{1..n}

  这就保证了所有operation的后验条件均是正当的正确的。

3、对于每个查询和命令,采用一个合适的先验条件

  每个真理都是在一定的前提之下才成立的。如果某个查询操作不需要先验条件,那么它的先验条件就是any precondition.

  这和前面所说的后验条件结合在一起,保证了Operation的组合的正则性。这里也强调了合适

4、撰写不变式来定义对象的恒定特性

  对象的某些属性自始至终都是需要满足某些条件的。仔细地区分地话,我们应该更加关注那些在command operation里面会改变的属性,确保这些属性一直满足这些条件,从而保证data满足不变式的要求和恒定特性。就C++而言,这点是需要特别留意的,一般建议在子类里面不要直接操作父类成员变量,否则对于保证对象成员变量的恒定特性是很麻烦的,在C++里面还有友元函数,友元类等,建议尽量不要在友元函数、友元类里面修改类成员变量值。对于成员变量的修改建议抽取出一个方法供调用,这样子,对于保证data的恒定特性非常有必要。

 

契约式设计(DbC)感想(二)