zoukankan      html  css  js  c++  java
  • 大闸蟹的 O O 战记

    一、 第四单元架构设计分析

    第一次作业,UML类图

    第一次作业的主要任务是完成对UML类图的解析并实现查询等操作,需要在课程组给定的框架中添加函数。对于UML类图,其存储是按照元素来存储的,其将所有的类图中的对象,属性,关系等都视作元素,按照元素类型存储着相关的量。我们要做的工作,就是对这些元素进行分类储存,将其实现为有利于查询的结构。

    我的理解是,本次作业中,所输入的数据都是自底向上的,而需要我们进行的查询过程是自上而下的,我们要完成的任务其实是将一个个的元素还原为图的结构,来进行存储与查询操作。故我新建了存储方法、接口、和类的三个类,用来存储UML图以及实现查询等功能。

    对于方法类,其中需要存储方法本身的名字,包含的参数等基本属性,对于存储类的类,需要存储其包含的属性、方法、继承关系、关联关系以及实现关系等,对于接口,由于跟接口有关的查询操作只需要考虑其及继承关系,故只需要存储其继承关系即可。

    类图如下:

    这次作业总体来说比较简单,在与同学交流的过程中甚至发现暴力遍历也是可以的23333

    第二次作业,对类图、顺序图、状态图的 解析以及有效性的检查

    第二次作业,在第一次作业的基础上增加了顺序图、状态图以及有效性的解析。对于顺序图和状态图,在阅读了大佬们在讨论区的讲解之后,其本质上和第一次作业是一样的思路,新建几个类来存储他们的信息即可。关键在于有效性的检查。对于第一个检查,要检查类中的属性与连接对端是否重名,但在实现过程中发现,还需要对类中的重名的属性进行检测。对于第二个检查,要检查循环继承。我采用的做法是将继承关系以及实现关系看作一样,使他们构成一个图,然后对每一个顶点查看是否有到自己的路径,如果有的话就有循环继承。对于第三个有效性检查,是要检查重复继承与重复实现。我采用的检查方式依旧是遍历图,看是否有多条路径到同一个点。在实现的过程中,我发现不同id但相同的继承关系在图中只会被计算一次,所以需要单独计算,并且所有能够到达这个点的点都应该加入重复继承的矩阵中。

    类图如下:

    在具体实现的过程中,发现如果将所有的代码都放在一个类中,会远远超过500行,故需要写多个类分别实现官方的接口,然后在标准的这个类中实例化其他的对象并且在构造方法中将数据传到其他的类中。

    在debug的过程中,发现有好多对于指导书理解有问题的地方,遇到了无数空指针异常报错,是一个浩大的工程。

    二、架构设计及oo理解方法的演进

    第一单元,是我们刚刚解除面向对象的单元,完成的任务是逐渐变得复杂的多项式求导。由于刚刚解除面向对象,我们采用的还基本上都是面向过程的思维。我采取的都是采用正则表达式去匹配然后进行分割计算。对于数据的储存,第一次和第二次作业是使用数组等存在一个类里,并没有将其构建类去分类储存计算。在第二次第三次作业时,由于需要支持嵌套,不得不将每一个因子构建类去逐层匹配并进行嵌套的求导运算。然而,由于对面向对象思想的不熟悉,采取面向过程的思路去写,代码量很大,问题层出不穷,导致对于第一单元作业都能够很快过掉能看见数据的中测但在强测中大面积爆炸。

    第二单元,是多线程单元,任务主要围绕电梯系统。多线程是我们新接触的东西,所以刚开始非常混乱,完全不理解多线程的含义,胡乱写了好多个不知道是什么的版本。在多次与同学交流的过程中,才逐渐一点点理解了多线程的含义。这一单元的作业我都采取的生产者消费者模式,每一次作业都是在上一次作业的基础上进行增添。在关于如何判断电梯停下来这个问题上,我花费了很多时间去设计,最终确定为向调度器中传入一个null并且监视电梯中是否还有运行的人来判断结束。多线程单元强制我们使用面向对象的思维去看待问题,去编写代码,虽然是一个十分痛苦与坎坷的过程,但确实是我们飞速地理解了面向对象地思想并且加以运用。

    第三单元,是JML单元。这一单元向我们介绍了JML规格,企图使我们的代码标准化。这一单元我们通过下载官方包,在其中根据给定的规格来填写函数完成功能。对于前两次作业,按照官方给的规格就可以简单完成。但是,这一单元对于运行时间有着限制,需要我们合理地合计和采用数据结构。自从这一次开始,我就基本全部换成了HashMap。第三次作业,是一个比较复杂的地铁线路系统,需要我们完成图的遍历等操作,而由于题目比较复杂,官方给出的jml规格也十分复杂难懂,最后基本变成了数据结构还债作业0.0

    第四单元,使UML图单元。作业主要完成的任务使UML图的解析工作。在经历了前几个单元的练习,这一单元虽然工程量很大,但是写起来并没有之前那样吃力。使用面向对象的思想,建立类去储存和实现数据的相关操作,使得这一单元作业的完成逻辑很清晰,bug也明显减少。

    三、测试的理解与实践的演变

    第一单元的测试基本上都是手动敲一些数据,寻找一些极端的数据来进行bug测试,效率较为低下。在进行测试结果的检查时,由于有些数据较长,对于输出的结果正确性判断也有一些难度和问题,并且由于输出也应该合乎给的规则,对于输出正确性的 检查也有很大问题。

    第二单元,由于是多线程,并且调度方法不一,输入的数据得到的结果有很多种,并且bug基本无法复现,测试功能也比较难以进行。

    第三单元,在指导书的指导下,我们解除了JMLUNITNG,Junit等工具。但是在大面积测试中,这些方法效率还是比较低的。故我采用生成随机数据并且跟自己写的以及同学的比较的方式来进行。但是由于进入强测之前无法获取其他同学的代码,故自己测试的时候基本只能测出空指针异常等错误,问题还是比较大。

    第四单元,是最后一个单元。由于是最后,在自己写完之后我也去要了同学的代码一起进行测试来找到输出结果不同的数据。得益于此,这一单元强测基本上没有bug出现。

     四、课程收获

    1.学习了面向对象的思想。之前学的基本都是面向过程的语言,解决的问题也都是一些规模比较小的问题。但在面对大规模的问题时,分类分块去解决是非常重要的。采用面向对象的思想更加利于我们之后参与项目的开发。

    2.学习了测试的方法。之前由于是可以看见测试数据的,基本是面向测评编程。而OO课程采取中测+强测+互测的方式,要求我们要完全找到程序中的错误进行修改。这极大的锻炼了我们思维的逻辑性、严密性以及测试的能力。

    3.提前体验了社会中的程序员生活。在大企业中,都是存在着测试与开发人员分工的。互测阶段让我们提前体验到了程序员间关于bug的惨烈战争。(以及经常熬夜肝代码的夜生活0.0)

    4.代码规范有所提高。之前,我写程序基本只是为了完成作业,完全没有代码规范的概念。这次,由于checkstyle的存在,对于代码的合理安排以及规范表达都渐渐使我规范了我写的代码。之前的汉语拼音命名法也改正了过来。

    五、建议

    1.关于实验课的安排。感觉oo的实验课相对于作业来说有种无关紧要的感觉。并且实验的时间紧跟在理论课之后,都没有时间去理解与消化,安排有些不太合理的地方。

    2.作业的难度或许有待调整,第一单元的最后一次作业对于刚接触的我们难度有些大。第三单元的最后一次也基本完全偏离了JML而变成了数据结构和算法竞赛。

    3.希望能够提高中测的数据强度以及覆盖面,不然经常出现中测过了但是强测因为一个小bug全面爆炸

    4.希望强测的梯度不是简单的增加随机代码,我这种非洲人很多次因为一个小bug炸掉了近乎全部的强测,而欧皇有很多bug甚至测不出来。

  • 相关阅读:
    OAuth2集成——《跟我学Shiro》
    Spring的servlet context和application context
    Spring MVC中如何指定某个类或方法自适配地响应某个HTTP请求?
    spring security的标签库
    使用 Spring 2.5 基于注解驱动的 Spring MVC
    在数据库历史上最重要的人物简介
    工作流引擎Activiti使用总结
    Activiti初学者教程
    比较Activiti中三种不同的表单及其应用
    Activiti工作流引擎使用
  • 原文地址:https://www.cnblogs.com/duanzhengxu/p/11070686.html
Copyright © 2011-2022 走看看