ADT与OOP：设计规约（specifications）

1.    前言

       本文章的内容：

       （1）方法的规约，理解其前置/后置条件与开发者和使用者的关系。

       （2）前置/后置条件的意义。

       （3）欠定规约，非确定规约

       （4）陈述式，操作式规约

       （5）规约的强度与比较

2.    规约Specification

    （1） 规约的作用：

             -精确的规约，有助于区分责任

             -客户端无需阅读调用函数的代码，只需理解spec即可

             -规约可以隔离“变化”，无需通知客户端 

             -规约也可以提高代码效率

    （2） 行为等价性：

        是站在客户端视角看行为等价性的。

        可以根据规约判定是否行为等价，而与其具体实现无关。

        如：

        

        他们虽然在找不到val时，返回值不同，但均符合以下规约：

        

        因此在此规约下，其行为等价。

3.    规约的结构：前置条件和后置条件

    （1）前置条件：对客户端的约束，在使用方法时必须满足的条件 

             后置条件：对开发者的约束，方法结束时必须满足的条件 

             契约：如果前置条件满足了，后置条件必须满足

                        前置条件不满足，则方法可做任何事情。   

    （2）Java中的规约：

            静态类型声明是一种规约，限制前置条件和后置条件，可据此进行静态类型检查

            static checking。

            方法前的注释也是一种规约，但需人工判定其是否满足。

            前置条件：@param

            后置条件：@return 和@throws

            如：

            

        （3）mutator方法：

            注意事项：

            -除非在后置条件里声明过，否则方法内部不应该改变输入参数

            -应尽量遵循此规则，尽量不设计 mutating的spec，否则就容易引发bugs。

            -程序员之间应达成的默契：除非spec必须如此，否则不 应修改输入参数

            -尽量避免使用mutable的对象 ：

                因为程序中可能有很多变量指向同一个可变对象（别名） ,

                而又无法强迫类的实现体和客户端不保存可变变量 的“别名”

                可变数据类型导致程序修改变得异常困难 

4.    设计规约：

    （1）主要有三个方面：

        规约的确定性，规约的陈述性，规约的强度

    （2） 规约的强度：

        如何比较两个规约，以判断是否可以用一个规约替换另一个？ 

        规约的强度S2>=S1,表现在：

        S2的前置条件更弱，而后置条件更强，

        这样S2就可以替代S1。

        因此，要使spec变强，就要使用更放松的前置条件+更严格的后置条件。

        例如：

                

            越强的规约，意味着implementor的自由度和责任越重，而client的责任越轻。

        （3）规约的确定性：

            确定的规约：给定一个满足precondition的输入，其输出是唯一的、明确的

            欠定的规约：同一个输入可以有多个输出

            非确定的规约：同一个输入， 多次执行时得到的输出可能不同 

                欠定的规约通常有确定的实现

        （4）规约的陈述性：

            操作式规约，例 如：伪代码 

            声明式规约：没有内部实现的描述，只有 “初-终”状态 

            声明式规约更有价值 ：内部实现的细节不在规约里呈现，放在

               代码实现体内部注释里呈现。

5.    规约图（Diagramming specifications）：

    图中每个点代表一种可能的实现方法。

    某个具体的实现，若满足规约，则落在其范围内；否则，在其之外

    在规约图中：更强的规约，表达为更小的区域 ：

    

    因为：更强的后置条件意味着实现的自由度更低了，更弱的前置条件意味着实现时要处理更多的可能输入，实现的自由度也低了，因此面积更小。

6.    规约的质量指标

（1）内聚性。Spec描述的功能应单一、简单、易理解

（2）信息丰富性。不能让客户端产生理解的歧义

（3）强度足够强。见前文

（4）强度又要足够弱。太强的spec，在很多特殊情况下难以达到。

（5）在规约里使用抽象类型，可 以给方法的实现体与客户端更大的自由度 

注意：客户端不喜欢太强的 precondition，不满足precondition的输入会导致失败。 

惯用做法是： 不限定太强的precondition，而是在postcondition中抛出异常：输入不合法 

是否使用前置条件取决于(1)check的代价；(2)方法的使用范围 

-如果只在类的内部使用该方法(private)，那么可以不使用前置条件，在使用该方法的各个位置进行check——责任交给内部client； 

-如果在其他地方使用该方法(public)，那么必须要使用前置条件，若client端不满足则方法抛出异常。