标签：arr 后置 规约 方法 实现 第五章 设计 前置条件

第五章设计规约

与第四章关注编程语言中的“数据类型”，“变量”，“值”，尤其是mutable和immutable的类型/值/引用不同本章节转向“方法/函数/操作”如何定义——编程中的“动词”、规约

规约

行为等价性：指的是在遵守规约的前提下，一种实现可以代替另一种实现，那么就符合行为等价。（单纯看实现代码并不足以判定不同的实现是否是行为等价的）

规约的特点：前置条件和后置条件

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

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

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

规约应该只讨论方法的参数和返回值，不讨论方法的类的局部变量或私有域。

在java中将前置条件卸载@param注解中，后置条件卸载@return和@throws中，下面是一个写规约的例子

/**
 * Find a value in an array.
 * @param arr array to search, requires that val occurs exactly once in arr
 * @param val value to search for
 * @return index i such that arr[i] = val
 */
static int find(int[] arr, int val)

对于可变方法的规约

应该遵守的规则：

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

设计规约

规约应该关注确定性，陈述性，强度。

一个规约S2比另一个规约S1强当且仅当它满足下面两点：（更强的规约可以替换弱的规约）

• S2的前置条件比S1弱
• S2的后置条件比S1强

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

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

非确定的规约：同一个输入， 多次执行时得到的输出可能不同（为避免混乱欠定的规约等价于非确定的规约）

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

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

声明式规约更有价值应为内部实现的细节不在规约里呈现，放在 代码实现体内部注释里呈现

图表规约

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

这其实就是一种可视化的图片方便理解规约的强度，更强的规约，表达更小的区域。比如下面这张图所示：

好的规约

• Spec描述的功能应单一、简单、易理解
• 对方法的调用应该信息丰富的，不能够让客户端产生歧义
• 规约应该足够强（太弱的spec，client不放心、不敢用 (因为没有给出足够的承诺)。 开发者应尽可能考虑各种特殊情况，在post-condition给出处理措施。）
• 规约也应该足够弱（太强的spec，在很多特殊情况下难以达到，给开发者增加了实现的难度（client当然非常高兴））
• 在规约里使用抽象类型，可以给方法的实现体与客户端更大的自由度（目的是希望方法的实现着总是提供接口，比如Set的输入和输出，而不是HashSet或TreeSet的输入和输出）
• 是否使用前置条件取决于(1) check的代价；(2) 方法的使用范围 如果只在类的内部使用该方法(private)，那么可以不使用前置条件，在使用该方法的各个位置进行check——责任交给内部client；如果在其他地方使用该方法(public)，那么必须要使用前置条件，若client端不满足则方法抛出异常

标签：arr,后置,规约,方法,实现,第五章,设计,前置条件
来源： https://www.cnblogs.com/pluschen-stack/p/14979299.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。