• OO2019第四单元作业总结


    前言

    本单元是oo课程的最后一个单元,四个单元来,自己确实收获良多,在此做一个总结纪念一下令人难忘的oo课程~

    本单元架构设计

    第一次第二次作业都涉及到了分类分级的思想,有类专门与外界信息交互,有三种图的处理,信息整合的包。让整个代码的架构更方便地搭建起来。

    第一次作业

    base包中是各种自定义的UML类,analyse包中是对类图元素的分析器。

    MyUMLInteraction是与外界传入的每一个元素、指令进行交互的窗口;analyse是元素的分析器,对外界传进来的每一个UML类图元素进行分类,信息归整;base包中是各种自定义的UML元素类,方便对一些元素进行扩充。

    第二次作业

    第二次作业在第一次的基础上进行扩展。新加了合法性判断和对流程图状态图进行分析的功能。

    sequencegraph包中包括了对顺序图进行一系列存储归类查询的功能;stategraph包中包括了对状态图进行一系列存储归类查询的功能。对类图合法性的判断还通过analyse类图分析器实现。

    类图的合法性检查,有三点原则:(1)类的attribute、关联对端重名(2)循环继承(3)重复继承

    这些都在建立MyUMLClass、建立MyUMLInterface的时候实现,进行记忆化。

    四个单元中架构设计及OO方法理解的演进

    第一单元

    第一单元前两次作业自己并没有什么架构可言,基本上每次作业都在重构,很少复用上一次作业的代码。从第一个单元的3个类到第二次作业的5个类,虽然也算是按照功能进行划分,但是总感觉整个编码的过程并没有那么顺畅,类之间也没有完全地做到各司其职,有一定的杂糅。

    架构设计较为合理、编码较为清晰的要数这一单元的第三次作业。这次作业用到了继承,对factor的各个分支划分(三角型、多项式型、数字型、幂函数型……),使得递归下降使用地更加清晰方便。

    这一个单元中,通过与OO的初接触,我大致了解了什么是类,什么是对象,有时候把思维抽象成为面向对象型的会更方便我们解决一些问题,让我们将问题拆分、逐个地去解决问题。

    第二单元

    第二单元的三次作业基本上做到了复用代码,各个类也基本上做到了各司其职。这次作业带给我最大的感触是,一个好的架构能够让代码实现的更方便轻松、bug能够更快地检测出来、整个功能的扩展优化也变得更加方便。

    在第三次作业时候,虽然做到了对前两次作业代码的复用,但是实现思路十分受限,调度器的局限性使得我最直接的想法就是把指令拆分、放进调度器。但是更好、更优化的实现思路则是根据各个电梯的实际运行情况,将人动态地分进各个电梯。之后想要优化的时候,发现,由于架构的局限性,使得自己的优化之路举步维艰。

    在这一单元中,让我感受最深刻的就是架构的设计,多线程冲突的避免。也渐渐掌握写面向对象思维的代码的方法。

    第三单元

    第三单元引入了JML,引导我们用面向对象的思维写出规格化设计的代码。在本单元的代码中,实现了逐层构造,架构合理。在整个单元代码的完成中,感觉十分顺畅,这也告诉我们,一个良好的架构设计能够更好地提升编码效率,减少我们代码bug的出现概率。

    第四单元

    第四单元可以说是这几次作业中,架构设计最复杂的一次作业。但是复杂不一定代表优美、容错率高,在这次作业复杂的基础上,我发现很多重复编码、对象间内容重复嵌套交互的地方,这样无疑增加了debug的难度与复杂度,也在一定程度上限制了代码的执行效率。

    但是规格的设计大体上我觉得还算合理,能够一眼看出整个代码的实现思路,问题到底出在哪里?我觉得这还是一个需要长时间探索、实践、总结经验的过程。这也说明了真正理解面向对象的思维、真正做到代码设计符合工程美学还需要很长的探索过程,需要我们不断积累~~

    测试理解与实现的演进

    在第一单元测试过程比较弱智,是手动地去构造一些边界数据或是读代码。认为构造出好的数据需要对整个代码实现过程十分熟悉,不放过任何一个坑点。

    第二个单元初次接触到了自动化测试,自动化测试主要由数据构造器和评测器两个方面构成。本单元的数据的构造器能够较为简单、思路清晰的实现,但是评测器的实现确有一定的困难,要求满足各方面的限制(人要有进有出、全部捎带完成、符合各个电梯楼层限制、进出时间符合限制都等)。 第三个单元初次接触到单元测试,也是自动化测试发挥作用最大的一个单元。首先单元测试通过构造一些容易出错的数据实现对方法的单个测试,能够更加精准地定位bug。其次是单元测试,让我认识到,好的测试需要考虑多方面因素,让测试集更具有针对性,有效指令比例更大。比如,增加环路,记忆化生成数据。

    第四单元的测试主要是构造一些UML图测试,这需要对代码的实现、对代码实现的难点、细节部分充分熟悉。

    总的来说,这四个单元的oo作业让我对测试的理解逐渐深入、也能够借助多种手段对代码进行更加全面的测试。

    课程收获

    oo课程虽然要结束了,但带给我的感悟与思考还远未停止,它潜移默化影响着我的思维方式。

    (1)面向对象的程序设计思想。

    贯穿整个课程始终的是面向对象的思维方式,使用这一思维方式编码,能够更好地做到代码的复用、架构的精简、设计过程的顺畅。

    (2)Java的编程思想

    java有类的继承、多态、抽象、抽象类等有益于整个代码更加简洁的小特性。合理利用这些小特性,我们能够更好地实现面向对象的编程。

    (3)测试方法的使用

    oo课程也让我最初接触到了代码测试。原以为代码测试就是给出一些边缘数据,手动测试,很少想到测试数据的合理性、覆盖性等问题。oo课程的的爱吗测试过程也是一个接触到诸多新知识、培养缜密思维的过程。

    (4)对代码的分析

    其实之前的每次博客作业,都有对本单元的代码进行分析。最初不太理解为什么要对代码进行分析。但之后,分析结果确实与自己代码实现过程中暴露出来的一些问题所对应上。这也指导了我去在下一次编码时更加注意到这些问题,尽可能地去改进。

    (5)架构

    随着作业的层层深入,要求的增加,我意识到一个好的架构对我们代码实现的帮助有多么大。一个好的架构不仅能够让我们更加快速地解决问题,还能够留足空间,共代码进行扩展、

    (6)多种有效工具的使用

    OpenJML、JUnit、StarUML、JProfile等工具,都是我们在这一个学期oo课程中使用到的一些工具。这些工具的使用和我们实际的编写java代码,实际上是一个相辅相成的过程,能够帮我们加深理解、更好地去实现代码、去发现代码设计中的一些问题。

    (7)总结与反思

    在最后一次研讨课上,hdl大佬的总结发言让我十分佩服。如果没有每次作业的总结反思、深入思考、用心设计,是不能够如此娴熟地结合我们的作业讲解。这也告诉我们,要学与思相互结合,及时总结反思,能够帮助我们更好地重新出发。

    课程建议

    (1)调整课下实验时间

    上午实验,下午上机的时间稍显仓促,能否给同学们更多理解、消化缓冲的时间呢?

    (2)性能分比例合理化,强测分数优化。

    其实性能分的概念只在一二单元中出现,但是它还具有存在意义,因为衡量一个代码实现好坏的远不止它的正确性。所以性能分存在还是很有必要的,如何更好地激励大家去得那些性能分,我觉得合理规划它的比例是一个很好的举措。

    其实我觉得程序还应该具有架构分、维护性分(如看上一次编码的复用比例)等。

    (3)互测

    其实后几次作业的互测,大家参与的积极性普遍不高。因为确实也可能在同一个屋中,大家都找不到对方的bug,通读代码的任务也确实有些大。或许可以不同档的人分在一个屋子,或者缩小一个屋子中人员的个数。

  • 相关阅读:
    sql中的Bulk 导入txt文本
    通过SQL自动添加流水号
    JAVA XML格式化输出
    nginx 服务端口权限13的问题
    使用hangfire在xunit中
    自动提交代码
    系统性能测试
    前端性能——速度之书
    node fs相对路径
    yum 初始化国内
  • 原文地址:https://www.cnblogs.com/GeXiaoXiao/p/11079513.html
Copyright © 2020-2023  润新知