软件构造04

规约(specification)

方法或者说函数,是程序的积木,可以被测试 、使用。使用客户端的方法无需关注方法本身的具体实现，使用它的抽象作用或者是能力即可。

对于程序员自己

我们实现一个方法之前首先得知道这个方法是用来干什么的吧，因此我们编写出spec，明确写出这个放啊要实现什么，有什么限制。
而基于这份spec，在实现之前，我们编写黑盒的测试用例

对于程序员与客户端之间：

程序员如何完成对方法的抽象，使它可以被客户端知道并正确高效的使用呢？

辅助程序员完成对方法的抽象的正是方法的spec（规约）

1. spec,即程序的规约，是程序员和客户端之间的一种契约.Spec给“供需双方”都确定了责任，在调用的时候双方都要遵守

2. 规约可以隔离变化，在我们重构该方法时，只要符合规约，就可以在不用通知客户端的情况下完成重构。

   那如何判断两个函数是否可以替换？

   Behavioral equivalence (行为等价性)
   (站在客户端视角看行为等价性).根据规约判断是否行为等价
   这两个函数符合这个规约，故它们等价

3. 规约的强弱判定：
   一个规约的构造：

   Precondition (前置条件) indicated by the keyword requires
   Postcondition (后置条件) indicated by the keyword effects
   Exceptional behavior(意外行为): what it does if precondition violated
   如果前置条件满足了，后置条件必须满足

   根据LSP原则
   前置条件越弱或不变，后置条件越强或不变，意外行为越具体或不变（例如抛出异常由Exception->FileNotFoundException/不抛出异常 ）
   的规约越强或不变。

   注意：不抛出异常比抛出一个异常的意外行为更具体，因为无意外行为代表你只要符合条件就不会有意外，是一份很强的契约

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

   Diagramming specification：

   

   某个具体实现，若满足规约则落在圈内不满足在圈外
   程序员可以再符合圈内的实现中任选。

   • 更强的后置条件意味着实现的自由度更低了->
     在图中的面积更小
   • 更弱的前置条件意味着实现时要处理更多的可能输入
     实现的自由度低了->面积更小
     前置规约变强，后置规约也变强的规约与原本规约强度无法比较。

4. JAVA中的规约

   那对于JAVA而言，方法的规约如果不受限制，不同程序员可以写的千奇百怪，因此要提到JAVA的API文档，符合Java doc规定的spec写法可以生成一份api文档的文件。

• Parameters are described by @param clauses and results are
  described by @return and @throws clauses.

• Put the preconditions into @param where possible, andpostconditions into @return
  

• 注意一个java方法规约应该只讨论方法的参数和返回值不讨论局部变量或私有域设计具体实现的内容

标签：04,规约,前置条件,specification,程序员,方法,spec,客户端
来源： https://www.cnblogs.com/yuesiyuan/p/16374294.html