第八次oo作业

作业五

作业五是当前最后一次电梯作业,也是我们第一次接触到多线程编程,输入方式也由之前的一次性输入变为了实时输入,其中涉及到大量的同步和冲突,其中学习多线程的使用也花了大量的时间,但总的来说为以后的作业打下了基础。

类图

1346314-20180502161653072-162868658.png

代码分析

1346314-20180502161711863-2007526753.jpg
从上述分析来看,此次作业仍然存在God类,究其原因主要是因为第一次接触多线程,使用不熟练,导致对电梯使用多线程时不敢将太多逻辑置于电梯类中,从而导致了大量逻辑代码都留在了调度类中,但调度类中的方法较之于之前已经更加详细具体了,方法之间已经尽量做到了高内聚低耦合。

总结

由于从第一次做电梯作业开始,我就是使用的模拟的方式,所以程序整体的逻辑上没有进行大的修改,但由于此次多线程的使用,尤其是多台电梯之间捎带和请求分配之间的问题,依然存在着不小的问题,所以到最后提交时,依然存在着bug————调度类中逻辑较为复杂,而且由于多线程控制不到位,对于请求队列没有完全实现线程安全,导致会出现多个电梯同时分到同一个请求的情况发生。但由于修改量的巨大,所以未能完成修改,而测试者也将为完成的修改造成的bug找了出来。

除此之外,此次作业的时间控制也不够精确,此次作业没有考虑到程序执行带来的大量误差,直接采用了sleep(3000)的方式,导致随着程序的运行,误差会越来越大,以至于超过误差限度。
但此次作业也第一次采用了构建一个State类的方式,将常用到的状态量定义为常量,极大的提高了代码整体的可阅读性。

作业六

作业六是要求实现一个简单的ifttt,将我们所学内容与实际运用结合了起来,但由于对于文件操作的不熟练,在编写代码时也遇到了不小的问题。

类图

1346314-20180502161730787-499369437.png

代码分析

1346314-20180502161746585-375564525.jpg
此次作业代码量和风格的控制较于第五次作业有了较大的提升,同时对于多线程也能够较为熟练的运用了,此次作业的自由度较之于之前的作业也有所提高,故readme的书写也应该被逐渐重视起来。

此次作业被找出了一个bug,但严格意义上来说并不能算是bug————在编写代码的时候发现一个问题,如果对于两个除了名称其余完全相同的文件,如a,b,如果在两次扫描周期中我们将b重命名为c,将a重命名为b,对于程序来说其实并不好判断其究竟是上述操作还是直接将a重命名为了c,所以我在readme中定义如果发现有重命名,而且有多个符合要求的文件,那么我会随机选一个视为修改,对于其他的,例如路径移动也是同理。但测试者可能因为没有仔细阅读我的readme,所以报了几个bug,全部都是因为这个原因。同时我测试的同学也考虑到了类似的事情,但他的readme中定义方式为对于上述这种情况,不能在同一个周期内同时操作两个除了文件名其余属性均相同的文件。代码中实现方式为将上一次扫描中没有出现的文件作为修改后的文件,可以说完全杜绝了这种情况的发生。在最后考虑到自己在readme中定义的是出现了某种情况应该怎么解释,而不是如何避免出现这种容易导致矛盾的操作,所以我最后也同意留下一个bug。

总的来说,此次作业是比较熟练地使用了多线程编程,但仍有一些没有考虑充分的地方,在以后的作业中也可以多注意一下这一块。

作业七

类图

这次作业是第一次出租车作业,相对于之前的几个线程,此次直接将出租车数量提高到了100个,对于此我是采用了开了100个出租车线程来解决,但同时也带来了内存占用巨大的结果,也有同学采用伪多线程的方式(如我测试的同学),采用循环来执行这100个出租车。对于此种方式我认为也算是一种解决问题的方式,但也难以锻炼自己多线程编程的能力,尤其是对于线程安全的控制,所以在以后的作业中我依然会采用100个出租车线程的方式。
1346314-20180502161805182-1200295103.png

代码分析

1346314-20180502161820734-1366118467.jpg
此次作业的代码风格算是这么多次作业以来最好的一次,加之此次也较为强调代码规范问题,所以整体来看代码基本能实现一看就懂的程度了。

但此次作业也是最不甘心的一次,但是可能是因为eclipse的bug,我最后一次提交时,本地显示已经提交了,但git上并没有提交,所以最后互测的时候交的是一个错误的版本,导致了此次作业的bug都是原本能够避免的。同时由于此次作业最开始没有发现自己的代码没有成功上传,所以在互测时测试者发现的bug在我这完全不能复现,甚至让我怀疑对方是在恶意找bug,不过好在最后发现及时(就没来得及进行代码层面以外的交流了)但也给我提醒了以后在上传了代码以后最好能够再下载一遍以确认是否正确。

此次作业做得比较好的一点(虽然最后代码没传上去)是时间控制,我一直都采用的系统时间,没有进行假时间的操作,所以此次在State类中我可以说是自己定义了一系列新的时间方法,例如sleep时首先将当前时间进行计算,计算出真实的需要sleep的时间后再执行,可以说此次作业在时间上的误差是严格限制在了误差范围之类的。

心得体会

这几次作业都是多线程作业,随着几次作业的进行,我对于多线程的运用也逐渐熟悉了起来,同时代码风格和规范也得到了不小的提升,像之前作业中的每次新的作业基本都要重写一遍代码的情况可以说基本也不会再出现了。希望自己在后面的学习中能够得到更大的提升。

转载于:https://www.cnblogs.com/AlbertShen99/p/8981253.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
用面向对象方法和面向对象程序设计语言,实现满足下述要求的一个高层建筑电梯活动 仿真程序。 问题域概述 某国际展览中心共 40 层,设有载客电梯10 部(用E0~E9 标识)。 限定条件 (1) 电梯的运行规则是: E0、E1:可到达每层。 E2、E3:可到达1、25~40 层。 E4、E5:可到达1~25 层。 E6、E7:可到达1、2~40 层中的偶数层。 E8、E9:可到达1~39 层中的奇数层。 (2) 每部电梯的最大乘员量均为K 人(K 值可以根据仿真情况在10~18 人之间确定)。 (3) 仿真开始时,各电梯随机地处于其符合运行规则的任意一层,为空梯。 (4) 仿真开始后,有N 人(0<N<1000)在M 分钟(0<M<10)内随机地到达该国际 展览中心的1 层,开始乘梯活动。 (5) 每位乘客初次所要到达的楼层是随机的,令其在合适的电梯处等待电梯到来。 (6) 每位乘客乘坐合适的电梯到达指定楼层后,随机地停留10-120 秒后,再随机 地去往另一楼层,依此类推,当每人乘坐过L 次(每人的L 值不同,在产生乘客时随机地 在1~10 次之间确定)电梯后,第L+1 次为下至底层并结束乘梯行为。到所有乘客结束乘梯 行为时,本次仿真结束。 (7) 电梯运行速度为S 秒/层(S 值可以根据仿真情况在1~5 之间确定),每人上下时 间为T 秒(T 值可以根据仿真情况在2~10 之间确定)。 (8) 电梯运行的方向由先发出请求者决定,不允许后发出请求者改变电梯的当前运 行方向,除非是未被请求的空梯。 (9) 当某层有乘客按下乘梯电钮时,优先考虑离该层最近的、满足条件(8)、能够 最快到达目标层的电梯。 (10) 不允许电梯超员。 开发结果的行为特征 (1) 产生事件的周期为1 秒,每次可产生0 个或多个事件。 (2) 各随机事件由互不相关的伪随机数发生器决定。 (3) 设计一个易于理解的界面,动态显示各梯的载客与运行情况,动态显示各楼层 的人员停留情况与要求乘梯情况;动态显示从仿真开始到目前的时间。 (4) 显示时用应表示出不同的乘客及其当前所要求去往的楼层。例如,12-32 表示标 识为12 的乘客要求去往32 层。 (5) 统计各梯的运行与空闲时间;统计各人发出乘梯要求后的等待时间;仿真结束 后显示这些时间。 (6) 参数K、N、M、S、T 应从命令行输入。 (7) (选做)考虑有些乘客(随机决定)携带的物品体积较大,需占用1~2 人的电 梯空间(随机决定),且上下梯的时间比其他乘客长一倍的情况,再进行相应的仿真(注意, 不是所有的乘客都携带较大体积的物品)。这时,显示乘客及所去往的楼层时要能够识别出 是否携带了较大体积的物品。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值