OO第三次总结

规格化设计的发展历史

        1950年代，第一次分离，主程序与子程序的分离结构是树状模型，子程序可先于主程序编写。通过使用库函数来简化编程，实现最初的代码重用。产生基本的软件开发过程：分析—设计—编码—测试，使大型软件系统的开发成为可能。

       1975—1980年代，第二次分离，规格说明（Spec）和体（body）的分离说明是类型定义和操作描述，体是操作的具体实现。（具体的例子就是C++,Java等面向对象语言的类说明与类实现的分离。）解决方案设计只关注说明，实现时引用或者设计体。体的更改、置换不影响规格说明，保证了可移植性。支持多机系统，但要同样环境。此时产生了划时代的面向对象技术。

       1995—2000年代，第三次分离，对象使用和对象实现的分离基于构件开发：标准化的软件构件如同硬件IC，可插拔，使用者只用外特性，不计内部实现。Web Services：软件就是服务。分布式，跨平台，松耦合。

 

规格化设计为何得到大家的重视

　　一方面，规格化设计可以帮助开发者理清思路，构建一个写程序的框架，这样一来开发者可以按照既定的套路来完成自己的任务，从而能够摒弃杂念，提高效率。

　   另一方面，一个程序中很多代码会以一块一块的形式被反复使用，这些重复的代码块有可能被封装为函数反复使用，也有可能被放入库中供他人使用。如果能按照一定的规格去完成他们，那么调用者不必大费周折的去理解代码，可以通过已有的对于格式的学习以及清晰明了的格式来快速完成对代码的理解，从而提高学习工作的效率。

 

被报告的规格bug

　　很幸运的是，我的JSF没有被人报BUG，虽然我的JSF写的不好，并没有用布尔表达式把他们实现，并且大量使用了汉语。再具体分析，我的JSF对于因果逻辑上的判断不够严谨，自然语言有些粗糙且不能充分展示细节，这些都是自己程序里的缺陷。

 

JSF不好的写法

　　如上一条所言，我的JSF大量使用了自然语言，这是最不好的地方。倘若我使用了纯粹的布尔表达式，也可能会犯过于简略的毛病。但是有的类又写的很长，如果完全按照要求来写，那么会使得JSF特别长从而难以理解。所以最好的办法是在设计的时候就做好规格化的设计，使得程序的每个模块都大小适中，这样组织起来才能井然有序。对于问题的处理也务必要清晰，不可以模糊，不可马虎大意。

 

功能BUG

　　这几次出租车作业的BUG相对来说不算太多，第九次的问题有出租车可以接单但是没有接单的情况，原因是请求的线程没有及时将请求加入请求队列中，在进行了相应的阻塞后得以解决。第十次的问题是LoadFile加载出租车多量的时候出现了问题，原因是在出租车队列初始化之前就进行LoadFile改变了出租车的状态，但是在初始化之后出租车的状态又变回去了，再调整了代码顺序后问题得到解决。第十一次作业没有被检查，自己不太强的测试没有找到BUG。