OO第三次总结

（一）总结介绍规格化设计的大体发展历史和为何获得了人们的重视

　　早期程序的代码量不是很大因此人们没有意识到规格化设计的重要性，但随着人们需求的增长以及程序功能性的加强，程序代码量愈来愈大，一我的没法完成庞大程序的编写和维护的工做量，但编写代码的人不必定会是维护程序的人，在阅读代码进行维护时给维护人员带来巨大的阻碍。因此代码规格应运而生，经过代码规格能够更快的了解相应代码的功能而不须要去阅读源码。大大便捷了程序团队编写和程序的维护。所以规格化设计愈来愈获得人们的重视，并成为业内的共识。

（二）规格bug分析

3次互测中都没有被找到规格bug，但本身的规格撰写仍是有待提高的。

（三）规格很差写法的改进

 

REQUIRES	原写法	改进写法
sortPath	src != null; dst != null;	0<=src.x<80 &&0<=src.y<80 &&0<=dst.x<80 &&0<=dst.y<80
initmatrix	None	map!=null
OpenPath	p1!=null&&p2!=null	p1!=null&&p2!=null &&graph!=null &&road!=null &&map!=null
Req	time!=null &&src!=null &&dst!=null;	time!=null &&0<=src.x<80 &&0<=src.y<80 &&0<=dst.x<80 &&0<=dst.y<80
gettime	None	this!=null

EFFECTS	原写法	改进写法
offer	\!IfIn ==> Grabque.offer(taxi); taxi.creditUp();	(old)Grabque.contains(taxi) == false ==> Grabque.contains(taxi) == true &&Grabque.size() = (old)Grabque.size() + 1
poll	\result == reqs.poll();	(old)reqs.isEmpty == false ==> \result == (old)reqs.poll() &&\(old)reqs.contain(\result) == false &&reqs.size == (old)reqs.size - 1
INFO_all	(\all int i; i<num.TAXINUM ==> System.out.println(taxis[i].comString());	(\all int i; 0<=i<num.TAXINUM ==> System.out.println(taxis[i].comString());
PointManager	\this.n == 0; * \this.points == 出租车在从抢单位置到服务完 该次请求所通过的全部的Point序列;	\this.n == 0 &&(\all int i; 0<=i<record.pickpath.size ==>\this.points.contian(record.pickpath.get(i)) == true &&\this.points.size = (old)\this.points.size + 1;

 

(四）bug与规格分析

	bug
第九次做业	未被测试
第十次做业	边界上红绿灯没法变换
	没法打开关闭的道路
第十一次做业	未按照最小流量跑

感受功能bug和规格bug目前看来还没什么明显的关系。由于目前为止都仍是先写的代码再写规格。

（五）心得体会

这三次做业的代码量相较前一轮明显少了很多，主要是为了培养咱们代码规格的撰写规范。但不是每一个人的水平都达到了那种境界——就是先写规格再写内容，大部分同窗应该还都是先写的内容并debug后再进行规格的撰写，但两次上机实验课让我明显体会到了规格撰写的重要性，有了一个描述无缺的规格再对内容进行编写是很容易的一件事。因此规格撰写水平的提高对程序员来讲很是重要，本身也须要多花点心思在这方面上。