规格说明：
是团队开发的关键，有利于分工合作
有利于确定方法实现者责任是什么
便于说明错误的位置和责任
以上就是所说的前置条件
对于实现者有好处：可以自由选择实现方式
在规格说明中如果告诉用户输入的合法条件，那么可以省略检查代码
写的程序计算机要能够理解（编译器），其他人要能够理解（规格说明和代码规范）
行为等价
如果规格说明中限制了输入，那么相似但不同的函数结果可能是等价的
1.前置条件：precondition（给用户）
想要函数履行职能需要的条件
遇到异常怎么办
2.后置条件：postcondition（给开发者）
前置条件得到满足的前提下，要能够提供正确的值
如果没有明确指出来，输入值是不可变的（尽量采用不可变的变量）：
对象的多引用，会需要维护程序的一致性
可变对象难以理解，难以确保正确性
可变对象会减少程序的可修改性
方案：
1.加要求，告诉用户不能修改，否则后果自负（用户可能强行或者无意间误修改）
2.要求实现者返回时生成新的实例来返回（开发者自己依然有可能误修改）
3.使用不可变变量来实现，比较可靠
但是可变对象性能很好，所以我们还是有时要使用它
具体到java语言：
静态检查可以解决一部分前置后置条件不满足的情况
使用@para描述输入
用@return（正常情况下）和@throws（异常）来描述输出
/**description。。。
*@para 。。。。
* @return。。。。
*/
写前置条件和后置条件如果按照规范来jml可以识别
黑盒测试：关键就是看规格说明书
白盒测试：按照代码结构进行测试，但是也是要符合规格说明
确定性分类：
1.确定性的规格说明：
有前置条件，一定会有唯一的后置条件，不会出现多的条件
2.低确定性的规格说明：
3.不确定性的规格说明：
不同时间，同样输入，同样实现，实现结果不一样（设计时间函数等情况）
为实现者提供了自由的空间
规格说明的替代：
若是用新的说明规格S1去替代原来的规格S2
那么最好满足：S2前置条件（输入i 限制）要弱（更容易适应），S2后置条件（输出结果更加精确）要强（答案要更果断）
这样才能保证原来使用适用的输入仍然适用，并且返回值更加符合要求
琐记：
list是一个接口，arraylist是实现方式
假定变量类型
编程要像一个悲观主义者，测试优先
是团队开发的关键，有利于分工合作
有利于确定方法实现者责任是什么
便于说明错误的位置和责任
以上就是所说的前置条件
对于实现者有好处：可以自由选择实现方式
在规格说明中如果告诉用户输入的合法条件，那么可以省略检查代码
写的程序计算机要能够理解（编译器），其他人要能够理解（规格说明和代码规范）
行为等价
如果规格说明中限制了输入，那么相似但不同的函数结果可能是等价的
1.前置条件：precondition（给用户）
想要函数履行职能需要的条件
遇到异常怎么办
2.后置条件：postcondition（给开发者）
前置条件得到满足的前提下，要能够提供正确的值
如果没有明确指出来，输入值是不可变的（尽量采用不可变的变量）：
对象的多引用，会需要维护程序的一致性
可变对象难以理解，难以确保正确性
可变对象会减少程序的可修改性
方案：
1.加要求，告诉用户不能修改，否则后果自负（用户可能强行或者无意间误修改）
2.要求实现者返回时生成新的实例来返回（开发者自己依然有可能误修改）
3.使用不可变变量来实现，比较可靠
但是可变对象性能很好，所以我们还是有时要使用它
具体到java语言：
静态检查可以解决一部分前置后置条件不满足的情况
使用@para描述输入
用@return（正常情况下）和@throws（异常）来描述输出
/**description。。。
*@para 。。。。
* @return。。。。
*/
写前置条件和后置条件如果按照规范来jml可以识别
黑盒测试：关键就是看规格说明书
白盒测试：按照代码结构进行测试，但是也是要符合规格说明
确定性分类：
1.确定性的规格说明：
有前置条件，一定会有唯一的后置条件，不会出现多的条件
2.低确定性的规格说明：
3.不确定性的规格说明：
不同时间，同样输入，同样实现，实现结果不一样（设计时间函数等情况）
为实现者提供了自由的空间
规格说明的替代：
若是用新的说明规格S1去替代原来的规格S2
那么最好满足：S2前置条件（输入i 限制）要弱（更容易适应），S2后置条件（输出结果更加精确）要强（答案要更果断）
这样才能保证原来使用适用的输入仍然适用，并且返回值更加符合要求
琐记：
list是一个接口，arraylist是实现方式
假定变量类型
编程要像一个悲观主义者，测试优先