OO第四次博客作业(第四单元作业及期末总结)

(注意:本文写作顺序与作业要求不完全一致,但涵盖了作业的所有要求)

  一学期的BUAA特色OO课程结束了。

PART 1  我想先写我这一学期的感想

  从第一单元满怀期待地写完多项式求值到最后看着60分不到的成绩伤心欲绝(这个词用的其实并不是特别夸张),到第二单元作业在截止前两小时还在做不停地思考和调试,再到第三单元在活页纸上记下一种又一种可能的实现方法(然后还有一堆bug2333),最后到第四单元,也就是这个单元的与考期共舞,与程序广度作斗争,每个单元都是你从未玩过的船新版本(因为OO课程改革所以还真的是船新版本),每一次作业都带来完全不同的体验。虽然写作业的期间,不仅是我,好多人面对满屏的代码和各种各样毫无逻辑的bug陷入自闭,但一旦挺过来,回头一想,自己确实完成了一些规模比较大,架构较为复杂的项目,而且是在比较短的时间限制内完成的,虽然还是不能从根本上改变咸鱼本鱼的本质,但至少算是做了比较大的努力,实现了一些以前自己不敢想的事情吧。从一学期的OO课程一步步走过来,回过头发现,自己真的走过了一段很远的路了。

PART 2  写完感想再写一写对OO课的祝愿,感觉这样行文比较流畅

  之前的博客作业没少发过牢骚了,这一次,作为课程的结束,想发自内心祝愿这门课在以后能越来越好,能为学弟学妹们提供更好的指导作用。虽然,按当今的社会状况,不要说一门课,通过整个大学阶段的学习,也很难从本质上改变乃至塑造一个成功的人,就好比只能对一棵已经长成的树做一些修修剪剪,而不能从一棵小树变成一棵参天大树。但是,我还是希望,哪怕只是想象一下,让学了这门课的学生,至少有一个自信,他能够胜任一些中小型的企业工程项目(更激进一点的想法,应该是大中型),有能力去企业做一些相关的实习,更好地与未来的工作相接轨,而不要让他们感觉自己无论学没学,都还是一条不中用的咸鱼。

  如果说具体做法,首先既然谈到实习,那如果有可能的话,可以真的为学生提供哪怕只是一周,或者一个中型Project的实习机会,去与工业界最亲密地接轨。可能对于相当一部分人(也包括我),还是需要以类似于作业的形式进行逼迫(或者说被动)式的学习才能真的吸收一些东西,既然这样,那把他们置身于工业界,置身于职场,在那种紧张的环境下,可能是对他们更加直接的逼迫,让他们感受到从构思到测试以至release的每一环节的不可或缺,全过程地感受“钢铁是如何炼成的”,这里的钢铁当然是代码的“钢筋铁骨”。限于条件,也可以进行类似于工业环境的模拟,但总归是差了点感觉,尤其是在测试的迫切性上。感觉只有置身于工业级的程序发布环节之前,才有那种必须不断、反复进行测试的必要性和紧迫性,才会真的想去一遍又一遍地进行各种测试。

  另外,如果局限于作业的形式,我觉得我们写的程序虽然在难度上真的不低,但距离一个真正由现实用户使用的程序,还差了一个难度上不大,但对绝大多数程序都不可或缺的环节——图形用户界面GUI。虽然一般的程序设计课上,不太可能单独掏出一个板块来讲解GUI的设计,但我们BUAA的OO本来就不是一般的程序设计课,它是基于project来实践练习的课程,既然如此,何不让课程内容覆盖更加完整,来一学期”从内到外“的面向对象编程练习呢?个人甚至脑补了一个具体的实现方式:在project总数不变的情况下,把JML第一、二次作业合并,挤出一个做GUI作业的project(个人感觉,在工业上与学术界广泛使用的UML,比实际用的不多的JML反而少一个project,本身就不怎么合理,感觉UML是一张真正的蓝图,而JML更像是一种玩具),在最后一次作业中完成一个GUI的设计。测试时如果无法实现机评,就用人工检测的方法,检测程序是否能够通过图形界面操作,实现对应的功能。这样一来整个project的难度其实会相对简单一些,一定程度上减小了烤漆复习的压力。还可以采用比较特别的性能分区分方式{比如按UI美观程度给分,当然不要太过分,只要不是BAD UI就拉满),给之前单元学到快自闭的咸鱼们一个翻身的机会,毕竟作为一门课程,给予学生充分的自信心是必要的,总不能让人一直coding司马脸,debugging司马脸吧。

  上面的建议可能太过空想化,仅仅作为我个人的一点祝愿写在这里吧。另外一些细枝末节的建议,就是尽量让每次指导书的要求明确一些,不要有bug或者含混不清的地方吧。当然这个事情是不能强求的,我自己写的程序都有一堆bug,又有什么资格苛求别人呢。

  (以上三段在统计时每段算做一个建议吧,太长看不过来的话)

PART 3  回归本单元作业

  两次作业放在一起讲吧,懒得分段了,何况它们是包含而不是并列关系。

  这单元的作业,从难度上可能不是特别大,但广度上真可谓无可匹敌。先是关于UML类图的各种操作,后又扩展到顺序图和状态图,还要实现对类图的基本规则验证。这就直接导致了一个结果:最后一次作业的代码量远超之前任何一次作业,成为爆肝的有力见证

  一开始我想直接采取遍历输入的方式实现每个功能的操作,结果证明行不通(这不是必然的吗?)。之后便老老实实地按UML结构建立了保存类模型的struct,从class,到attribute、operation,再到parameter,一级一级建立起来一个完整的结构,也就意味着说初始化的时候要遍历至少三次输入。类和接口采用同一个结构模型,只用了一个boolean变量来区分二者。对于继承、实现、关联等各种各样的关系,采用两头区分的方法,以继承为例,有一个保存父类的ArrayLIst AppendFromList,也有一个保存子类的ArrayLIst AppendByLIst,这样就将所有的输入信息转化为便于处理的,类似于图的结构了。对于UML顺序图和UML状态图,我也采用了类似的处理方式。实际上,这次作业中相当的码量和时间,耗费在了结构的构造和构造方法的书写上。

OO第四次博客作业(第四单元作业及期末总结)_第1张图片

既然这单元学的是UML,那我就导出一个超级大的UML类图放在这里吧(手动滑稽)

  代码的核心逻辑部分,我觉得自己真的是吃了数据结构,尤其是图的部分没学好的亏,总是出问题,出各种问题,害得我半夜3点又烧脑又爆肝地debug。就算我投入了大量精力思考导致bug的原因,就算最后一次作业要求已经简化,强测的bug最后还是出在了图结构上。第一次的bug没什么好说的,没完成指导书要求(还真不是没看,解决方法都想出来了,感觉自己明明写了,结果发现没有,晚了!)加上迷信指导书样例,忽略了接口重名要重复输出这一点。第二次的bug,checkForRule008改了好几次还是挂了一个点,暂时先不管了,专心把博客写完,你看又半夜12点了。

PART4 总结四个单元架构设计和OO方法理解的演进

  因为寒假预习工作做的不错,至少在理论层面,对OO方法已经有了一定的理解。

  第一单元:理解归理解,在相当多的地方,面向对象的方法没怎么体现出来,无非是将表达式拆成了三个部分。但就是这门一分,带来了面向对象给我带来的第一份便利:化整为零,用简单、细小的部分拼凑成复杂的、庞大的部分,用简单、短小的方法去实现复杂、冗长的方法。虽然构造方法上,结构式编程的痕迹还非常明显,但封装、继承、接口实现等基本操作已经得到实现(P.S. 现在想起来第一单元作业还重复继承过接口2333),到第三次作业,已经不可能再用结构式的思维去实现,而凭借前两次作业的面向对象基础,就比较轻松地完成了。

  第二单元:与其说面向对象,不如说这一单元演练的是多线程编程的能力。可能在写的时候,并不觉得因为面向对象带来了多大的便利,不过后来证明那是因为多线程编程本身的难度,而不是面向对象方法不行(写完OS Lab4的fork函数就知道了)。这单元是最难的一个单元(虽然就这么一句话让我每次都有后面单元很简单的错觉,然后每次都写到自闭),最后一次作业更是难上加难,电梯的封装、调度器的实现、调度算法的选择、多个电梯线程与调度线程和输入线程的同步,随便一个都可以难倒一大片人。尽管最后没有难得地没bug实现了,但面向对象的程度还不够,代码耦合性比较高。

  第三单元:这次绝对是正宗的面向对象编程了,可惜封装的部分不是我们亲自完成,而是助教帮我们实现的。架构上也并不困难,就是典型的无向带权图,加上严格的卡时间限制,仿佛穿越回了一年前的数据结构课堂。但与之前不同的是,这次是采用面向对象方法实现的图结构,用更少的码量、更清晰的程序逻辑,实现了更为复杂的功能。

  第四单元:和上次类似,也是助教帮助我们进行的封装,而且这次帮得可以说更多,以至于架构占了码量的大头。而且架构实际上也有种还原UML图的意味,虽然工程量大,但难度上并不太高,甚至给了我一种再加把劲可以自己写出来个StarUML的错觉(被打醒)。

PART5 总结自己在四个单元中测试理解与实践的演进

  简直是哪壶不开提哪壶,丢人啊。看那个翻车的表情包我真是想笑又笑不出来。

  第一单元测来测去,覆盖性不足,扑街;第二单元,借助别人写的测试工具,好歹是测出了几个重要的bug;第三单元,感觉上没问题了,但感觉这个东西真的一点都不靠谱,想做一些测试,JML跑不了,想写JUnit,发现自己不会用,根本上还是测试不充分的问题;最后一个单元,迷信指导书样例,忽略重要情况。

  由此就可以看出一个要命的问题:覆盖测试。这里指的不是代码的覆盖,而是各种情况的覆盖,说白了就是多跑几组不同的样例。覆盖测试充分的程序,bug就少或者没有;没怎么进行充分测试的程序,bug就多得令人发指。基本的功能测试和单纯的边界测试并不困难,但想要做到覆盖测试却很难,最难的一点,就是很难通过人力来进行覆盖,测来测去总漏边界情况。关键是对于一个有bug的程序,它引发bug的边界是不确定的,这是我写代码的时候最最最最头疼的一点。

 

转载于:https://www.cnblogs.com/P-R-E-T-T-Y/p/11071174.html

你可能感兴趣的:(OO第四次博客作业(第四单元作业及期末总结))