标签:orm 置疑 理解 problem mil 面向 怎样 目的 color
规格化设计历史
规格化设计的历史目前网上的资料并不多,百度谷歌必应也表示无能为力......
在这里结合现实情况讲一讲自己对程序规格化的理解,首先代码规格化对代码的影响是间接的,或许它不能让你代码里面的bug直接消失,或许它也不能让电梯之间不相互阻塞,但是它能让OO实验拿到更多分啊//笑。玩笑归玩笑,下面具体分析一下规格化设计(JSF为例)的作用:
规格bug分析
自己写的代码规格基本上属于“你的代码真的很烂”级别,博主懒癌晚期,每次观测点的JSF属于随缘被挂状态。下面来分析一下这些垃圾代码,强迫症大佬谨慎食用:
/**@ REQUIRES: AllNode!=NULL;
* taxi!=NULL;
* loc= int[2];
* des= int[2];
严格地说Requires里面要对各个变量进行详细地规定,要是能与与repOK一致的话是最吼的:
/** @ REQUIRES: AllNode!=NULL;
* taxi!=NULL;
* (loc!=NULL) && (loc.size==2) && (All int i=1;i<=2;)==>(loc[i]>=0 && loc[i]<80);
* (des!=NULL) && (des.size==2) && (All int i=1;i<=2;)==>(des[i]>=0 && des[i]<80);
这几次作业在书写JSF规格时,更像是一种亡羊补牢的过程,首先要求我们具体实现一次代码,再向代码添加JSF,其实与规格化设计略有相悖,另外我认为课程组可能有一点点低估JSF的完成难度,一个优秀的后补JSF需要程序猿阅读自己都快忘了的一坨屎,读完后还需要将代码抽象出一般性的逻辑。以目前北航计算机系大部分同学的编程风格来说,数百行的类基本上比比皆是,数百行的方法也是大有人写,将三位行数的代码抽象出effects可不是一个简单的过程,而与此同时还要完成复杂的流量红绿灯设计以及基于gayhub的操作系统,这确实有一点点难了。不过在这几次公测中,我有幸抽到了一份JSF尚可的代码:
/**
* @REQUIRES:m!=null;
* @MODIFIES:\this.situation;
* \this.isCalled;
* \this.curTime;
* @EFFECTS:normal_behavior:
* 出租车行驶,\this.situation按照出租车的行驶情况不断变化;\this.isCalled在出租车成功接到单子时变为true;接单结束后变成false;
* exception_behavior(InterruptedException e):
* System.out.println("Oops," + this.toString() + " seems to have some problem.");
*/
如果没有记错的话自然语言描述依然是在允许范围之内的,当然就算不允许,我认为依然不应凭此扣分,毕竟从复杂的代码中抽象出effects还是一个工程量很大的任务。
心得体会
程序是让人看的,是要分享给队友或者老师,甚至是任何陌生的人共享交流。或许你的算法复杂度能做到o(1),或许你的代码可拓展性很强,但是这些都比不上一群与你一起开发项目的程序猿
,一群能读懂并指出你规格化代码bug的人。或许在这学期的面向对象课程中JSF是一个很烦人的存在,但是规格化程序设计的重要性是毋庸置疑的。
好像有点跳,可能接着更......
标签:orm 置疑 理解 problem mil 面向 怎样 目的 color
原文地址:https://www.cnblogs.com/gtwc/p/9094059.html