面向对象第二单元感想
面向对象第二单元感想
前言
这一单元的作业在规定时间内提交上去并且通过了的作业只有第一次，后两次作业都无效。第二次作业是自己没有解决调度器的问题，其实原因还是在于第一次作业做的太过简洁，第二次作业完全属于重构，没有一点需要用到第一次作业的东西，不过课下倒是稍微完成了一下，并没有达到正确输出的目的，总是会有逻辑上的问题，还有时序上的问题。第三次作业被限制在了CPU时间，wait和notifyALL的使用不够纯熟，而且采用的是半傻瓜调度（下面解释），也不知道会不会在中测卡住运行时间（只卡住时间提交了一次），以下进行这三次作业的具体分析和总结。
正文
第一次作业
结构
第一次作业用了极其简单的结构，双线程，三个类就完成了，uml图如下：
SRE实战 互联网时代守护先锋，助力企业售后服务体系运筹帷幄！一键直达领取阿里云限量特价优惠。
很简单的结构，电梯只进行指令的执行，并且可以通过轮询方式访问请求列表是否为空并且进行线程自主判断是否终止，请求列表进行指令存取，主线程进行指令的输入并且存入列表，没有使用任何时序上的判断，也不存在共用对象的冲突（一个存一个取），所以第一次作业会完成的比较快。优点：快速简单，既熟悉了多线程编程，又能够实现简单的单部电梯模型。缺点：不容易进行扩展，直接影响第二次作业的进行。方法数一定是电梯比较多，但是逻辑都部署在主线程，进行线程的运行和终止。
测试
测试方面倒是并没有大问题，互测阶段也没有被hack出bug。
第二次作业
结构
第二次作业相应的uml图只是在电梯和请求列表之间加了一个调度器线程，变为了三线程模式。这里没完成就不做展示了，调度器线程和电梯线程是第二次作业的两座大山，电梯线程我完成的应该到九成，但是奈何没有时间和精力搞定调度，极度的疲倦以及身上阵阵发麻的信息告诉我应该珍爱生命，就这样放弃了这次作业，究其原因，其实我感觉还是出在了最初纸面上的设计阶段，没能细化，只是单纯地认为加上调度器进行指令的判断调用就可以，忽略了电梯本身运行的逻辑其实也是一个巨量的工程，结果两头没能兼顾，翻了小船。
第三次作业
结构
第三次作业吸取第二次作业的教训，早早动工，注重保养，请教大佬······还是翻了车，话不多说，上uml类图：
上面Dispatcher类只是一个方法，目的是进行指令的判断和切割，即对新进来的指令判断是否需要两部电梯协作才能完成，如果需要则进行最优拆分（即不考虑电梯状态的情况下，用时间最少），并且将拆分指令插入请求列表中。Scheduler进行指令的分配，并且处理分割指令的运行顺序。由于第二次作业并没能实现可稍带，整体电梯内部使用傻瓜调度。优点：没啥优点，可能多线程之间的协作做的还不错，缺点：就是wait和notifyALL不会使用。在测试时改成whlie sleep是可以运行的，上交的那份作业是使用while sleep模式的，但都是real time error，CPU时间不符合。
小结
提前动手！提前动手！提前动手！
多交流，第三次作业深刻体会到这个道理，如果不是同学好心说了几句结构上的简化建议，我可能就像第二次作业那样啥都做不出来就完了，第三次作业课下修改空间很大，希望补给站的时候能过吧。
对待OO，心脏撒撒给油！
