• 第一次博客作业



       也许是完完全全按照指导书写的流水账,也许是对前三周兵荒马乱的OO生活的总结,也许是对写代码的一点点思考.....

     

    基于度量分析程序结构

     


     

    OO_1(多项式加减)

        第一次作业我设计了两个类,一个是Poly类,用来存储多项式的阶数和系数,并实现了多项式的加减方法。另一个是Main类,实现了正则表达式匹配,字符串分离提取和输出结果。在main方法中先判断表达式格式,然后实例化一个Poly对象,调用ParsePoly和ParseOp方法提取字符串中的数字和运算符,最后计算输出结果。

    ·度量:

     

    ·类图:

    ·优点:思路清晰,代码易读。

    ·缺点:大部分工作集中在Main类,Poly类所承担的任务较少。没有掌握好相关知识,不必要地使用静态变量,导致本次作业去掉了class之后就是一个巨大的面向过程式的程序。main中实现了太多功能,代码冗余。

     


     

    OO_2(傻瓜式电梯)

     

      第二次作业我设计了6个类。Request类判断输入要求的合法性正确性,如果错误做出相应的容错处理,如果正确则提取出参数;requestQ类初始化参数数组;dispatcher类实现调度计算。在main中构造一个floor类初始化楼层信息;再构造一个requestQ类的对象读入各行字符串,requestQ类中的input方法构造一个request类的对象判断字符串格式是否合法,若合法将返回的参数存入各个参数数组;接下来构造一个dispatcher类的对象,调用start方法,其中构造了一个elevator类的对象,根据指令输入顺序进行调度。

     

    ·度量

    ·类图

     

     

     

     

    ·优点:都是按照PPT上的规划写的(好像不是优点)。

    ·缺点:类之间的任务量分配不均衡,其中floor类没有起实质性的作用,调度器类里的功能只用一个方法实现,完全没有“面向对象”。程序中盲目使用static等修饰词。类之间的聚合度不够。

     


     

    OO_3(ALS式电梯)

     

       本次作业和上次的类数目,各类之间的调用关系一致,只是电梯的调度方法不一样。实现ALS调度的思路:遍历整个请求队列,若该请求未执行过让它成为主请求把它放入优先队列中(以楼层排序)然后扫描其后的请求;如果其后没有请求了,直接执行。如果其后有请求r,要求r能被捎带,然后得到响应时间,若响应时间>请求产生时间,并且优先队列中原先没有该楼层的请求,则标记已经输出加入优先队列,若优先队列中原来有该楼层的请求但是不同质,加入优先队列,若同质,将指令标记为无效输出之后,加入优先队列。如果请求r成功加入了优先队列,那么重新遍历从主请求到r中间的所有请求,找出能够继续被添加进优先队列中的请求;否则,跳过。不断扫描,直到扫描结束。更新主请求,继续循环。

     

     

    ·度量

     

    ·类图

     

    · 优点:减少了上次作业的代码冗余,将重复的代码段封装成方法,简洁了不少。

    · 缺点:类之间的任务量分配不均衡,floor类不过10行,scheduler类的一个方法就要100+行。SC类对scheduler类的继承没有体现出继承机制的优越性,而是相当于重写了整个类。每个类里面大量的get..,set..方法,写的时候有愧疚感,好像上课一遍一遍强调不要写get和set的荣老师在盯着我,责备我似的。还是过于面向过程了。

     


     

    Bug分析

    ·第一次作业:公测无bug,互测无bug。

    ·第二次作业:公测无bug,互测无bug。

    ·第三次作业:公测无bug,互测无bug。

    但是!写的过程中还是有一大堆问题的,我们后面再说

     


     

    Bug的策略

    首先就是用自己测过的样例(基本上是对分支树的覆盖测试)测一遍,然后看一下同学的正则表达式和格式错误时的判断思路,如果没有错用自己踩过坑的正常样例(通常非常大~)试一遍。

    第一次拿到的小可爱公测只错了一个点,是因为正则爆栈了。互测没有找到bug。

     

    第二次的大佬公测全对,但是如果第一条起始时间不为0输出ERROR后,后面的指令起始时间不为0不报错,直接正常运行。看了一下代码,应该是输入时只记录了输入的指令条数,没有记录合法的指令条数。

     

    第三次的大哥乍一看公测,一半飘红,基本上捎带的全部出错。但是仔细看错的样例,捎带顺序都是对的,时间是错的,应该是捎带时没有计算开关门的时间。互测时我基本没有测捎带,我用了几个不能捎带的样例,发现他在电梯上行状态r.n<=e.n时错误地捎带了。如果他课下多测几个样例,这种时间算错的bug应该能轻松地找出来。

     


     

    心得体会

    1、第一次作业刚开始想用有限状态机,然后很可耻地知难而退了。周日晚上写完了正则,周一晚上完成了整个程序。周二发现用大一点的数据计算地会特别慢,查了一遍发现我把一个要遍历整个数组的方法重复调用了好多遍。本以为这次作业皆大欢喜了,结果离DDL三小时发现正则爆栈了。心态直接崩,赶紧上网各种查又问同学,把原来的正则分成内部和外部比较,终于交上了作业。

     

    2、第二次作业明显难了,花了一天看PPT和指导书,基本了解了要实现那些类和哪些方法。格式检查和存数据部分和第一次没什么差别,很快就写好了。傻瓜调度也很简单,就是判断同质的时候费了一点功夫,为了代码简单我用了ArrayList,比数组容易操作而且不会溢出。

     

    3、第三次作业乍一看非常容易,只用改一下调度方式。上手才知道太麻烦了,光捎带就分四种情况,这还是指导书明确说明了的,更可怕还有主请求和同质请求的一大堆循环判断。开始打算用数组实现,结果变量太多写到一半就晕了,所以改用优先队列。优先队列是不同于先进先出队列的另一种队列。每次从队列中取出的是具有最高优先权限的元素。如果不提供Comparator接口的话,优先队列中元素默认按照自然顺序排列,也就是数字默认是最小的在队列头,字符串则按字典排序。如果想实现按照自己的意愿进行优先级排列的话,需要实现comparator接口。

      优先队列大概长这个样子:

     

    public class test {  
        private String name;  
        private int population;  
        public test(String name, int population)  
        {  
            this.name = name;  
            this.population = population;  
        }  
        public String getName()  
        {  
             return this.name;  
        }  
      
        public int getPopulation()  
        {  
             return this.population;  
        }  
        public String toString()  
        {  
             return getName() + " - " + getPopulation();  
        }  
        public static void main(String args[])  
        {  
            Comparator<test> OrderIsdn =  new Comparator<test>(){  
                public int compare(test o1, test o2) {  
                    // TODO Auto-generated method stub  
                    int numbera = o1.getPopulation();  
                    int numberb = o2.getPopulation();  
                    if(numberb > numbera)  
                    {  
                        return 1;  
                    }  
                    else if(numberb<numbera)  
                    {  
                        return -1;  
                    }  
                    else  
                    {  
                        return 0;  
                    } 
                }    
            };  
            Queue<test> priorityQueue =  new PriorityQueue<test>(11,OrderIsdn);  
             }  
    }  

     

      它可以自动根据捎带的优先级顺序将请求加入队列,在这次作业中真是帮了我大忙,当然大家可以自己实现一个优先队列。

    这次作业遇到的最难忘的坑是,每次进捎带队列的时候,要再判断一下当前的同质情况!我最开始忘记判断导致同质请求虽然没有被执行,但是捎带时还是算了它的开门时间。开始构造的数据太弱了,根本没检查出来这个bug。

     

    4、不要稍微有点思路就瞎写。第三次作业我把捎带想的太简单,第一遍写出来的东西不是不捎带就是进死循环。把需求弄清楚再写更节省时间。

     

    5、要和同学多交流,加深对指导书的理解。

     

    6、希望尽快学会调试,虽然print大法帮我解决了不少bug。

     

     

  • 相关阅读:
    spring + spring mvc + mybatis + react + reflux + webpack Web
    陈忠实和路遥:日他妈的文学和你懂个锤子
    Spring+SpringMVC+MyBatis+easyUI整合基础篇
    JAVA方法中的参数用final来修饰的效果
    全球晶圆代工厂哪家强?2016年Top30名单
    EXT combobox 二级连动 清空store缓存数据
    潘通
    MySQL性能优化
    启用了不安全的HTTP方法
    Hibernate一级缓存(基于查询分析)
  • 原文地址:https://www.cnblogs.com/qilingzi/p/8687125.html
Copyright © 2020-2023  润新知