zoukankan      html  css  js  c++  java
  • OO第9-11作业总结

    一、 规格化设计

        规格化抽象,即将执行的细节抽象为用户所需求的行为(模块做什么)。

      主要作用在于提高工程设计中的可维护性,可读性,明确功能,使整个编程任务变得清晰有序以减少程序BUG。

      说其发展历史,似乎显得有些牵强,因为“规格化设计”这个标准的概念还没有得到广泛运用以至于百度上进行查找全都是北航同学的博客……不过类似的规范化设计仍然在计算机编程中发挥着比较重要的作用,在面向对象中,其主要衍生于数据抽象和过程抽象这样的初始概念,之后由于代码维护的重要性结合面向对象的特点产生了规格化设计的概念,以此使程序层次分明有条不紊。

    二、作业中规格BUG总结

    第九次作业 :

      无规格BUG ;

    第十次作业 : 

      REQUIRES规格bug2个 ; EFFECTS规格bug1个 ;

      错误原因 : (1)前置条件整型变量未限制范围大于0 ; (2)前置条件格式不正确(old的使用) ;

           (3)后置条件用自然语言描述 ;

    第十一次作业:

      REQUIRES规格bug2个 ; 一个方法未写规格 ; 

      错误原因 : (1)前置条件整型变量未限制范围 ; (2)前置条件国歌约束之间使用 " ; " 连接而不是" && " ;

    错误原因总结:
      这几此作业的规格bug出现原因主要是因为未能覆盖所有方法的所有约束,以及某些细节的格式错误。

    三、规格改进实例

    1、前置条件实例

    (1)实例1

    代码段截图:

    前置条件更正为:

    time>=InitTime ;

    (2)实例2

    改进前:

    更正为:

    p1!=null && p2!=null ;

    (3)实例3

    改进前:

    前置条件改进为:

    command.detail.paidan!=null  && command.detail.paidan.way!=null && command.detail.paidan.waytime!=null ;

    (4)实例4

    改进前代码:

    前置条件改进为:

    time>=0 ;

    2、后置条件实例

    (1)实例1

    改进前:

    后置条件改进为:

    (exist int i; 0 <= i< queue.size;queue[i].from==this.from && queue[i].to==this.to && abs(queue[i].time-this.time)<100)==> esult==true;

     (2)实例2

    改进前代码:

    后置条件改进为:
    (all int i; 0 <= i< str.size;(new command(str).IsLegel()==true ==>queue.contains(command)==true)) ;

    四、规格撰写心得体会

      最后抒发以下自己这一个月的编程体会……

      不得不说这一个月是我大学以来最无聊的编程体验,因为几乎所有的时间都围绕着一个事情:扣分(不管是给别人扣分还是被别人扣分,如何写代码已经把“不被扣分”放在了首要的位置)……

      老师可能无法体会到目前学院的OO课程氛围是怎样的,毕竟作为决策者,中心是培养我们的能力,至于采取的措施能不能起到效果或者说能不能真正起到利大于弊的效果,目前确实无法下定论,但是可以肯定的是OO这门课程的学习氛围确实非常差,最明显的一点:每次周五十点以后朋友圈满满的负能量(这个各位同学应该是深有体会的)…

      我并不是单纯抱着吐槽的目的写这些感想,因为我并不否认课程组的初衷,规格化的编程思想在工程设计中确实是很重要的,但是出发点与实际情况常常会背道而驰,所以我想把真实情况放映出来,同时表达一下自己对于课程的看法;

      规格化设计的目的在于提高可维护性,提高可读性,明确模块的目的,通过编写规格的时间大大减少更多的debug时间和代码维护的时间,这样看确实应该起到“事半功倍”的效果,但是由于目前这种规格化设计的死板性和互测中标准的欠缺,我们目前的情况似乎是“事倍功半”,并且…直接导致了OO互测不再像是相互学习的途径,而更像是一场没有硝烟的战争,然而战争的结果却无法让人信服(这也是为什么目前OO课的课程氛围极差,充满了负能量);

      同为编程为基础,我想同另外两门课作为对比:

      一是大一的数据结构:大作业中同学们能真正通过对课程知识的理解和实践去探索挖掘其中的细节奥秘,以此不断优化自己程序的算法(尽管时间只减少了1毫秒,仍然是货真价实的提高);

      二是大二上的计组:要求及其严苛,但是标准统一,评分干脆,所以尽管艰难但是没有抱怨过了就是过了没过就是没过,心服口服。

      当然并不是说OO就一无是处,OO也有它的优点,并且面向对象本身的特性导致了很多时候在标准上就无法做到完全统一,但是针对目前OO课程的体系,是否可以借鉴一下这两门课的课程思想,尤其是改善一下学院内的学习氛围,如果一门课迫使大家一步步地把分数变为绝对核心,同时这门课带给大家的不是完成任务以后的兴奋和成就感,而是相互“损害”弥漫的负能量,想想还是挺悲哀的…

      撇开评价不说,其实还是需要感谢课程组对于每位同学的付出,毕竟有时理想与现实总不能做到统一,或许老师和助教也是无奈……

      只能希望这门课的体系能越来越完善,所有人的努力都会得到回报,共勉…

     

  • 相关阅读:
    js鼠标右键菜单
    js变量作用域好玩的东东
    清除浮动
    http通信示例Httpclient和HttpServer
    sql复杂案例
    微信小程序(小游戏)后台开发
    自动授时同步NTP时钟之NTP农历源代码算法立显电子技术部宣
    NTP同步时钟系统的实现及局域网授时方法
    modbus协议显示屏|modbus通讯显示屏|modbus显示电子屏功能码实现代码分享
    带掉电记忆功能的LED时钟代码分享
  • 原文地址:https://www.cnblogs.com/zgj982393649/p/9105713.html
Copyright © 2011-2022 走看看