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个人总结第二弹的主要内容,如果未能解决你的问题,请参考以下文章

Object Oriented个人总结第一弹

requests第二弹

秋招备战计划第二弹最后俩月能提升的知识清单

秋招备战计划第二弹最后俩月能提升的知识清单

十年网络安全工程师整理—100渗透测试工具使用方法介绍(第二弹)

日程管理系统代码维护第二弹(结队编程)