oo第二单元总结

面向对象的程序设计(2019)第二单元总结

 对问题的初体验

　　oo第二单元便开始进入多进程，和第一单元相比，个人感觉电梯显然更考查我们面向对象思想以及怎样写出清晰简单的建构。在正确性之上还考验我们进一步优化的能力（虽然我每次的优化好像都是负优化，哭了）。多线程的自测也是一大难题，我用java的process实现分时投入就搞了将近一天。最后正确性就只能靠自己肉眼看四五百行的输出了。开始感觉oo不只是做作业而已，围绕着每一次的作业自己都可以去尝试新的东西（自己测试，自己搭一个简陋的评测机等等）。只是感觉时间不是太够，毕竟每周还有os课设。

单部电梯设计思路

　　第一次作业傻瓜电梯就不用多讲了。两个线程，主线程读入，在开一个电梯线程。

　　第二次作业加上捎带之后其实感觉难度提高了不少。尤其是对于第一次接触多线程的我们来说。和第一次相同，还是主线程实现读入，另外在开一个电梯线程和调度器线程。电梯和调度器各有一个请求队列。电梯每到一层就和调度器进行一次交互。原本以为通过中测之后以为自己的正确性就差不多了。但是随机的几组数据便被测爆了。原因是一个乘客可能会多次进入电梯。显然还是自己在最初构思的时候没有把所有的情况都考虑到。解决掉正确性之后开始考虑优化。因为自己的调度器写得比较丑陋，所以在调度上优化的空间其实很小了。在我的优化方案中，不存在所谓的主请求。每到一层，当电梯与调度器完成数据交互之后便扫描整个电梯里的请求队列，找到与电梯当前运行方向相同，同时楼层距离当前楼层最远的请求来决定电梯的运行方向。之后我随机用几组数据进行了对比，发现比不优化的版本确实要好一点。但是强测的分比人家只有捎带不优化的还低。表示很无奈。

　　第三次作业。讲道理如果不考虑性能问题其实蛮简单的。电梯线程基本不用改，只不过多开了几个线程而已。需要处理的就是某些请求需要拆成两部分，还是有强制的先后关系。然后在处理一下每个电梯的停靠楼层便完事了。但是我这样实现的最后一个中测点始终过不去。先是静态地读了一遍代码，分析了一下可能出现逻辑错误的地方。发现没有错误。之后便将所有可能的换乘进行排列组合。还是没有发现错误。从周日一直到周二晚上一直没有发现bug。最后无奈，随机生成了40条指令，然后对比五百多行的输出才发现了错误所在。原来是在程序运行中它有可能本身在一楼停靠，在得到请求执行的时候，会输出ARRIVE -1。但又不是每次都会这样。改完bug之后只剩下一个半小时了，想优化也没时间同时也没有优化的思路。

度量评价

类图（着重分析第三次作业）

 

　　从类图中可以看出，其实自己的每个类还是太过臃肿。elevator类和manageRequests类都有将近300行。而且有时候一个对象被传递的太多。使得维护起来很麻烦，很有点c语言式程序的味道。同时基本上是都在电梯类内部完成电梯本身的调度，使得三个电梯其实是彼此分离的，没有充分发挥出调度器的作用，电梯之间不能够相互合作，使得优化做起来很难。

 

类复杂度分析

类方法复杂度分析

　　不同类之间的复杂程度相差很大。不够面向对象，不少地方都只是为了能够完成需求，而没有考虑到架构的优美性设计。elevator类中的很多方法都可以做一些改进，有些方法甚至是多余的。第三次作业架构真的很差，（花了将近一整天的时间debug）优化就更无从谈起了。

bug分析

　　这三次作业公测和互测都没有被找出bug。

个人总结

　　感觉自己还是花了太多的时间在保证正确性上。导致没有更多的时间和精力来优化自己的架构，尝试很多新的方法。比如第二次互测看见同组的同学有使用单例模式，就准备在第三次作业是写单例模式，因为把调度器对象传来传去总感觉不舒服。但是第三次正确性一直得不到保证，所以就没有用到单例模式。第三次我还想尝试使用除了sychronized其它的方式来实现锁的功能。但还是没有时间来做进一步的优化。这些只有看到第三单元有没有机会做了。

　　然后，觉得自己在做oo作业整个过程中，其实可以学到很多东除oo之外的东西。比如说用shell脚本来实现自动化测试，用java的process来开一个子进程等等。（但是我就没时间做优化了）

 

转载于:https://www.cnblogs.com/731338514-yin/p/10753039.html