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