Object Oriented个人总结第二弹
Posted wangkexiang
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Object Oriented个人总结第二弹相关的知识,希望对你有一定的参考价值。
一、 分析和总结自己三次作业来的设计策略及其变化
a) 第一次作业
比较幸运第一次接触多线程的时候就可以遇到最后的方案,这次作业我运用的是synchronized+notified的策略,通过电梯线程和scheduler线程互相唤起来实现多线程的运行,而在线程不进行计算的时候就让现场wait。这样将线程的工作时间和强度降到最低,同时也保证了绝对的安全。
b) 第二次作业
由于要求限制,不得不放弃安全好用的线程互相唤醒的机制,使用不断循环扫描实现,通过每隔一定时间扫描一次进行一次快照,记录当前监控对象的状态,这种机制面临很多问题,比如如何保证一次扫描之间不会进行两次操作,好在最后对此进行了限制。
c) 第三次作业
单纯的synchronized,这次使用的县城方法比较简单,为了防止100个线程对系统资源利用过多,产生不可预料的后果,我将100辆车合并到了同一个线程,用轮询进行车的移动,车移动完之后在进行派单,虽然方法略显粗暴,但是效果奇好。再辅助以假时间的方法,可以解决非常多的问题。
二、 基于度量来分析自己的程序结构
a) 第一次作业
UML图
类图
有一些方法由于刚开始的时候没有考虑清楚,写的太过臃肿,这种现象主要是集中于带有大量条件判定的方法。关于条件判定的方法比如电梯选择,可稍待判断等可以继续优化。
优点:整体设计比较清晰
缺点:条件判定想得不够清楚带来冗余。
设计原则不足:存在GOD类
b) 第二次作业
UML图
类图
与上次相比较略好一些,但是对于不同的触发器操作写到了一起。导致了方法的臃肿。
缺点:针对不同情况的操作写到了一个类。
设计原则不足:Dependency Inversion Principle,责任均衡分配原则
c) 第三次作业
UML图
类图
比之前的好了很多,分派方法嵌套太深。
优点:责任分派相对均衡。
缺点:方法调用深度过深。
设计原则不足:重用原则,有功能重复的类。
三、 分析自己程序的bug
a) 第一次作业
所交版本为调试版本,所有同质请求,未按照格式输出。
b) 第二次作业
无bug
c) 第三次作业
输出格式错误扣一分
将3000毫秒误计算为14个200ms的周期逻辑错误。
d) 基本都挺脑残的。。。没啥可分析的。
四、 分析自己发现别人程序bug所采用的策略
a) 第一次作业
基本输出错误格式错误。
逻辑错误
仅靠前两项已经扣的有点多了,心软没有继续查下去
b) 第二次作业
边界测试,测出程序不能监控识别文件夹的最后一个文件
c) 第三次作业
对方由于版本问题,没有考虑gui带来的延迟导致了一系列错误。
同时依靠边界数据测出一个逻辑bug
d) 没有发现线程不安全的问题,拿到的基本上写的都不错,但是相比前三次作业而言,从中可学习的东西不是特别多,也可能我自己进步了。
五、 心得体会
a) 毫无疑问notify+synchronized是现阶段最好的方法,即可以保证的线程的安全,又能降低线程的CPU占用。也更符合现实中的情况。
b) 第六次作业全局锁真的是反人类的东西,可还不得不用,杨帅提出的对象全局共享很有意思,被我改造用到了第七次作业。
c) 增强for循环还是个好东西,方便简单。学会使用@override等注解小技巧可以提高效率。
d) 第七次作业明显简单一些,可以花时间考虑设计,这个时候难度降低有一定科学性。
e) 千万不要临结束前一分钟提交,难保出不出意外。
f) 由于之后的自由度大大提高,需要适应新的互测形势。
g) 设计原则还需磨练。
以上是关于Object Oriented个人总结第二弹的主要内容,如果未能解决你的问题,请参考以下文章