标签：三次 细节 text 必须 状态 很多 多层 分享图片 data
先放上程序的度量图和程序的类图
这一次作业算是第一次接触多线程，整体还是比较蒙的状态，有很多地方的设计还不能很好的从单线程转换过来，导致这次作业被迫重构了好几次。虽然有一些重构，但是由于整体还是沿用之前的设计，所以各个类与方法之间的职能与界限都不是很清晰。在调度器类里，还是存在一个方法内有很多的条件、循环出现，也有很多层的嵌套。由于一直在学习多线程的机制，也就没能很好的对这些方面进行优化。和上次相比，把输入处理相关的各个类与方法的只能进行了一定优化，显得比之前清晰了一些。
缺点很明显，调度器类的功能过于强大，而且虽然类中对各个属性添加了private属性，但是在获取时还是直接返回了属性，没有能真正的起到保护作用。
这次作业投入的时间比较多，很多方面都考虑到了，也就没有被挑出bug
在互测的时候，对方的程序在输入判断时会出现空请求无法识别的现象，同质请求的处理也会出现问题，偶尔也会出现死锁。
最明显的感觉就是测试变得更加复杂了，代码的逻辑也不像以前那么直接了，而且会有很多边界情况的出现，需要更加注意。
这次作业圈复杂度高的原因是在扫描时有大量的条件判断，不过感觉这些判断之间的联系都比较紧密，分成单独的方法也不是很合适，就没有进一步的优化。在类图上可以看出明显清晰了很多，各个类之间交互也变多了，基本上做到了各司其职。
这次作业由于开放性比较强，自己在写的时候有些过分纠结一些可以自定义的细节，导致在算法设计上出现了一些问题。如果监控的目标是文件，采取重命名和更改路径操作时会出现识别错误的现象。
互测的事后并没有能够发现bug。
吸取了之前写电梯的教训，这次出租车写的时候考虑架构考虑了很多，逻辑上也相对清晰一些，一切都是围绕服务中心类展开。度量中出现的红字是提供的gui测试线程的问题，没时间再去管了。
多线程的时间处理一直都是很棘手的问题，程序运行的不确定性会影响时间输出结果。这一次就作死直接用了系统时间输出，就被找到了bug……而且在信用度处理上也是指导书读的不够细致，出现了错误，之后一定要小心了。
我测的程序和我一样也是有一个指导书理解的问题，输出的出租车停靠时间不对，还有就是一个时间逻辑上的bug。
这三次作业算是初步接触了多线程吧，多线程和单线程的差别真的很大，有很多冲突需要考虑。代码的执行顺序也很难保证，必须通过锁等方式进行控制。
我对面向对象的思想也有了更加深入的认识，也有了一定设计的意识，而不是像以前一样拿来直接写。
标签：三次 细节 text 必须 状态 很多 多层 分享图片 data
原文地址：https://www.cnblogs.com/liuhm98/p/8977103.html
