博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
第二次oo总结
阅读量:5045 次
发布时间:2019-06-12

本文共 923 字,大约阅读时间需要 3 分钟。

前言

  这三次的oo作业,相对于之前的难度是一个跃升。从大一的第二课堂,数据结构,到大二上学期的计组使用verilog编程,都没有接触过多线程这样的编程思想,尤其是第五次作业刚开始的时候,多线程确实让对多线程一知半解的我大费周章。不过在完成几次作业之后,也确实感觉到了多线程逻辑的简化和方便,但同时也会带来各种各样的麻烦。

 

第一次作业

  

 

  第一次作业由于是多线程的首次尝试,可以看出不同对象之间的调用非常杂乱,首先我使用main类作为主类启动三个elevator对象作为三部电梯线程,然后三部电梯每个电梯中有自己需要执行的请求队列,读取和处理请求也是不同的线程,处理请求和三个对象之间有交互。处理请求线程可以读取三个对象的状态,然后将指令分给应该执行请求的电梯的队列。另外,还有诸如LIght这样的其他类,用于对于同质请求的判断。

  显而易见,这样Command类作为请求处理的类运行的复杂度就会非常大。

 

第二次作业

 

  第二次作业的IFTTT由于指导书有很多不明白的地方,所以写的代码就很复杂,具体来说就是main类作为主类调用输入处理方法,输入处理将所有需要监控的对象归纳出来以后,启动对应的监控对象,我对于每一类的监控都写了一个类,由于对于线程安全的方法还不是很理解,所以我这里只使用了一个全局变量来确保线程的安全,但是这样还是有可能造成线程不安全的问题。

  由于输入处理完请求后需要对于指令进行判断并启动对应的监控线程,所以处理类的复杂度很高。

 

第三次作业

  第三次作业的类之间的联系就相对规整了一些,原因其一是使用了提供的gui类,二是因为逻辑相对简单。所以第三次作业的逻辑更加清晰一些,但是我的第三次作业仍有不足的地方,就是内存开的过大,而且还有一些我无法处理的误差。

 

后记

  这几次作业没有通宵过了,只是会看到凌晨4点的北京,感觉可能是相对来说更加适应了一些oo这门课,但是对于多线程的掌握仍有很大不足,应该更加勤勉一些。

 

posted on
2018-05-02 17:55 阅读(
...) 评论(
...)

转载于:https://www.cnblogs.com/tdnss-18/p/8981616.html

你可能感兴趣的文章
IIS的各种身份验证详细测试
查看>>
JavaScript特效源码(3、菜单特效)
查看>>
Linux常用命令总结
查看>>
yii模型ar中备忘
查看>>
C#线程入门
查看>>
CSS清除浮动方法
查看>>
JVM内存回收机制简述
查看>>
洛咕 P2480 [SDOI2010]古代猪文
查看>>
js-创建对象的几种方式
查看>>
JDK JRE Java虚拟机的关系
查看>>
2018.11.20
查看>>
word20161215
查看>>
12th week blog
查看>>
dijkstra (模板)
查看>>
python小记(3)
查看>>
编译Linux驱动程序 遇到的问题
查看>>
大型分布式网站架构技术总结
查看>>
HDU 1017[A Mathematical Curiosity]暴力,格式
查看>>
[算法之美] KMP算法的直观理解
查看>>
EntityFramework 性能优化
查看>>