zoukankan      html  css  js  c++  java
  • OO第二阶段作业总结

    第五次作业:

            设计策略

             本次作业设计的基本思路是按照指导书所给的推荐方法来完成的,即共用对象为队列盘,线程有电梯、调度器、以及扫描器,扫描器将控制台输入的有效指令加入到队列盘中,调度器依据指导书的原则分配任务给电梯,然后电梯将其一条条执行。在电梯的类中,加入了一个小队列,即电梯依次需要完成的任务。在同步控制中,对队列盘对象加锁,在某一线程使用时,其他线程无法更改,但是可以访问。这样存在一些时间上不同步的问题,导致了一些bug的出现。

             度量:

             类图:

             本次的类图较为简单,由于实际使用的类并不是很多,List类为扫描器,scheduler类为调度器,Elevator类为电梯,由于是三个电梯同时运行,因此实例化了三个电梯来同时运行。这次作业实现的好处在于思路简单,并且各类间的关系明确,易于在后续的找bug工作中提供帮助。但是缺点在于,类中只有run()方法,代码的可读性太差,没有将各个工作模块化,全部工作塞在一起显得臃肿,并且代码复杂度极高,导致一些不必要的问题出现。

             Metrics度量图:

             第一行的红色标记,表明了本次作业中,我对从控制台读取有效命令的方法部分模块复杂度过于复杂,并且嵌套深度也过深,这在第三行中也表明了出来。这依旧是因为,我在处理控制台的输入时,将正则判断也加入了这个模块,这导致了一个方法承担了许多任务和工作,因此让该模块的复杂度直线上升。并且对一条输入进行了多次正则匹配,也直接导致了模块代码的复杂度和嵌套程度加深。对代码的优化和提炼做得还不够。

             分析自己程序的bug和不足:

             本次作业出现了两个bug,一个是由于没有使用继承机制,直接使用了以前的调度器和调度方法。事实证明,偷懒是没有好处的,测试者真的很细心,这样都能发现我用了以前的调度器。另一个bug是如果最后一条命令是(#ER,1,1),我的程序就会crash,这依然是使用之前的调度方法的问题。还有一个bug测试者并未发现,在我的设计中,调度和扫描只能交替进行,这是由于对同步控制错误导致的。虽然没被发现,但是如果不及时改正,对接下来的其他作业必定会造成影响。这次作业还是存在许多的不足,某个方法依然显得臃肿复杂,模块化和可读性程度都极差。对线程的同步控制也是做得不够完美,在调度上也存在一些问题,导致了程序crash。

    第六次作业

             设计策略:

             这次作业是实现对文件的监控和管理,明白ifttt原理。虽然老师一直说这次作业很简单,但是我觉得一直写到深夜的应该不止我一个人。这次作业最大的难点就是,需要自己先自学java里对文件的操作怎么描述。这就花去了我许多时间。其实这次的作业难点在于架构,基本方面在于,扫描器扫描控制台的输入,读取文件的路径,监控内容等。在文件经过相应的操作后,能够作出对应的响应。并且需要写一个类,让测试者能够操作目标文件。我的策略就是每两秒扫描一次目标文件所在的文件夹,然后判断是否做出了监控器监控的动作,如果出现了,就执行需要执行的输出。按照指导书的要求,判断各个操作是否出现。

             度量:

             类图:

             其中List类是扫描器,负责处理控制台的输入。monitor类是监控器,也就是程序的主体,负责判断各个监控器的内容是否出现。detail记录了文件或文件夹的先后名臣,先后路径,先后大小和先后最后修改时间,并且输出到指定位置。summary类记录了监控器监控内容发生的次数,并且输出到指定位置。filevisit类是提供给测试者操作文件的另外线程。这次的优点在于我将detail和summary另起一类,让各个变量间独立,使结构更加清晰明了,输出到文件就不易于犯错。缺点在于需要在monitor中调用这两个实例化对象,会造成代码量变大以及monitor类中的变量增多,易读性就大大降低了。

             Metrics度量图:

             根据这次的metrcs度量图,可以看到已经没有红色的字体出现了。但是模块复杂度最高的还是我的扫描器对控制台输入的部分,由于这次对输入格式并未作要求,因此在正则匹配上就没有那么多的工作量,因此没有造成模块的过于复杂。嵌套程度最深的是我的监控器类的监控方法,由于调用了很多其他方法来监控文件,所以嵌套程度最深。这次对各个模块代码的优化和简练还是做得比较满意,模块化的程度也较高,并没有预料中出现过于复杂化的模块的出现。

             分析自己的bug和不足:

             这次作业的bug存在很多,主要原因是对recover要求处理不到位,对这个要求的并没有去测试,只是完成了基本代码,但是在自己测试的时候并没有考虑这个情况,因此就直接交上去了。然后错了一堆bug,才发现对recover,也就是将文件还原的操作是错误的,有时候程序还会不响应。后来在检查过程中才发现执行recover操作时,没有记录更改前目标文件的路径和名称,只是将文件的位置改变了而已,由此造成了极大的失误。还有一个比较严重的bug是没有设计好多个监控内容的情况,如果监控多个目标文件,时间上会不同步,导致输出到detail的最后修改时间错误。这是由于同步控制做得不好导致的。

    第七次作业:

             设计策略:

             这次作业要求完成一个基本出租车功能的程序。基本方法在于,由扫描器扫描控制台乘客的目的地和所在地,然后由调度器调度附近符合要求的出租车去接送乘客。本次作业的难点我认为在于去完成最短路径的寻找,虽然由GUI提供的方法能够稍微魔改一下去找到最短路径,但是会花费大概3~4秒的时间,初始化时间太长我觉得不太合理。就想到了数据结构使用的链表方法,使用了一个差不多的方法来查找最短路径,事实证明效果还不错。在程序实现时也直接引用了GUI的方法,让程序能够可视化。另一个难点在于圈出4*4区域,让进入的出租车能够响应。

             度量:

             类图:

             这次需要完成的类有很多,因此看上去结构比较复杂。这是主要的缺点。并且可以看到各类之间的互相调用很多,导致了程序的嵌套程度很深。但是结构上的复杂必然就会有思想上的简单。Dis类用来计算两点间的距离。map类用来从文件中读取地图。scan类即从控制台读取乘客的需求。queue类即等待对列。taxi类即是出租车类。各自处理各自需要实现的功能,不会互相影响,并且可读性极高,后续的debug工作容易进行,这也是本次作业没有被找出bug的原因之一吧。

             metics度量:

             第一行所指出的最复杂的模块是指导书所给的GUI模块中的让地图显示出来的部分。由于地图一直需要刷新,这是理所应当的。然后第三行,嵌套程度最深的又是我的扫描器的读取输入的函数。这次作业我对程序的优化和简练应该是做得比较好的,可能是由于这个线程需要一直从控制台读取有效输入导致的,这个线程在设计上是需要一直运行的,因为需要不断的接受乘客的请求。这是理所应当的。

             分析自己的bug和不足

             这次作业在互测阶段并没有被找出bug来,可能是测试者没有发现,但是我自己在设计中有个缺陷,这也是我交上去作业的一瞬间才想起来的。如果控制台同时输入两个或两个以上的乘客请求,我的程序只会响应其中的一个。另一个不足在于,对于指导书提到的4*4区域,如果出租车一开始在该区域,但之后驶出区域后,应当是加入抢单队列的,但是我没有 处理这个出租车。虽然侥幸没被测试出来,但是确实存在这些小问题。必须在下次作业之前改进。

    心得体会

             这三次作业据老师说已经是所有作业中比较难的了,希望如此吧。能够活过第二阶段还没有无效作业已经是万幸,希望以后也不要有无效作业出现吧。然后就是努力完善自己的程序吧,既然不喜欢给别人找错,那就让自己的程序变得更无懈可击就好了。

  • 相关阅读:
    【转+补充】在OpenCV for Android 2.4.5中使用SURF(nonfree module)
    Delphi StarOffice Framework Beta 1.0 发布
    Angular ngIf相关问题
    angularjs文档下载
    公众号微信支付开发
    公众号第三方平台开发 教程六 代公众号使用JS SDK说明
    公众号第三方平台开发 教程五 代公众号处理消息和事件
    公众号第三方平台开发 教程四 代公众号发起网页授权说明
    公众号第三方平台开发 教程三 微信公众号授权第三方平台
    公众号第三方平台开发 教程二 component_verify_ticket和accessToken的获取
  • 原文地址:https://www.cnblogs.com/y1027/p/8979452.html
Copyright © 2011-2022 走看看