第一次作业
(1)设计策略
设计策略,是几乎没有大的策略,模仿着ALS的调度方法,大致弄了个样子出来。
第一次作业的主要目的是熟悉单生产者,单个消费者的生产模式,熟悉共享对象的读写同步等操作。
电梯调度方面,实现了简单的捎带,调度判断等等策略,总的来说就是同楼层同方向的捎带,弱化版的ALS电梯
(2)可拓展性
如同前文所言,是弱化版的ALS,大部分时间集中在处理共享对象读取写入,进程的控制上面,忽略了电梯的调度,
使得运行时间非常长,可拓展之处在于优化电梯的策略,实现更快的调度
(3)度量分析
总体来说,并不复杂,最复杂的在于电梯run方法,以及共享对象里面对于存取的判断等,总而言之,第一次作业整体架构比较简单。
由于设计实在是太过于简单,只是单纯的生产者,消费者模型,共享对象只有增加,删除两个功能。
在SOLID原则上,单一职责并没有违背,里氏替换没有违背,接口隔离没有违背
主要违背的地方在于DIP原则,电梯和输入类,都直接依靠着共享对象类,而不是“依赖着抽象接口,在让共享对象类去实现这个接口"这种方式,
以及这种方式所导致的,开放封闭原则受到了影响。
但是总的来看,根据程序的总体设计,电梯的共享对象并不会出现巨大变化。
而且难以出现一个程序里面,不同电梯的共享对象的种类还要出现变化的情况,因为共享对象更类似于加了一些新方法的容器。
除此之外,严格来说,这个共享对象,算不上一个低级模块,只是充当容器的作用。
所以就没有设计接口,而是直接依赖实现。
(4)自己bug与别人bug
最大的bug来自于时间问题,运行的太慢了,导致rtle,这个问题改正方法就是重新写调度策略。
别人的bug并没找到,hack超时并没有成功
除此之外,提交之前最大的bug来自于电梯无法停下来,电梯线程无法结束,导致课下一直超时。
最终改变了一些种植条件,成功完成。
第二次作业
(1)设计策略
第二次作业,改动异常的少,甚至相比于第一次作业几乎没有任何变动
第二次的多部电梯,完全就是多个第一次的电梯共享一个队列,来回争取,没有任何调度策略。
但是实际测试中,没有策略的效果比一些调度策略甚至还好或者差不太多。
主要问题还是电梯跑的太慢了,拉了后腿。
总体就是,多个电梯,共享一个队列,然后互相抢夺
(2)可拓展性
由于电梯数目不确定,很难做针对性的调度策略,调度策略方面拓展性感觉比较小。
但是多个电梯,对于同一个队列的处理,有很高的拓展性。
比如3个从一楼去往3楼的人那边,一个电梯就够了,我却派出了三个电梯,导致运行的时候,电梯资源的浪费。
另外就是电梯还是比较慢,可以改进。
(3)度量分析
可以发现,和第一次作业相比,几乎没有任何变化,因为这次就是第一次基础上,加了多个电梯,共享一个队列而已。
同样的,因为设计的结构没改变,SOLID原则也和第一次一样,主要违背了DIP原则,顶层并不是面向共享对象的接口,而是直接依赖着共享对象的具体实现
同样的,由于违反DIP原则,导致在开闭原则上面也受到了若干影响。
前两次作业,违反原则主要原因是,我把共享对象当作了一个包含着新方法的容器类,具体实现上,共享对象也确实作为容器,按照容器的方式去实现了一些功能。
这样子的低级模块,就没有特意的去设计接口,而且严格来说,它也算不上是低级模块。
本着如无必要,勿增实体的想法,没有去迎合DIP原则的设计
(4)自己bug与别人bug
我自己和别人的主要bug,主要是两个System.in的缓冲区不共享,导致电梯会吃掉前面的人的情况。
主要原因是,主函数类里面,用一个输入读取总数,输入类里面,用一个输入读取人的信息,主函数输入没及时关闭,导致人的信息进入主函数缓冲区,主函数结束,信息也丢失。
改正方法就是及时关闭或者公用一个输入。
自己是在课下提交阶段找到的bug,hack别人的时候,没有hack成功,但是和同学讨论hack思路之后,他们hack成功
第三次作业
(1)设计策略
在第二次的基础之上,增加了特定层数可以停靠,也就代表着需要换程。
分析发现,所有楼层,最多一次换乘就可以达到,所以每个人进入之后,先交给调度器,规定好他的换乘楼层是哪里。
如果不用换乘,就直接把换乘楼层标记为目的地。
然后选择合适的电梯,加入电梯队列。
电梯只是负责把人送到他们的换乘地点,然后判断如果这个人换乘地点是目的地,就不用管他,
如果这个人换乘不是目的地,就塞回给调度器重新分配。
(2)可拓展性
主要是选择合适的换乘楼层和电梯。这次作业实现的时候,并没有仔细思考换乘策略,而是找到能换乘的站,就换乘。
这就导致了换乘有时候绕了一大圈远路,十分麻烦。
换乘策略上面有很大的拓展性。
(3)度量分析
总的来说,最核心的复杂度,在于选择合适的电梯换乘,以及选择合适的换乘站,这两个地方。
其中,选择合适的换乘站几乎占了复杂度的全部。
其他地方几乎还是和以前一样。
本次设计依然违背了DIP原则,没有对着接口设计,以及因此导致的开闭原则受到影响。
这次的类的设计上面很混乱,类与类的包含关系也十分混乱,有很大的重新架构,减少耦合的空间。
除此之外,单一原则也没有实现好,因为加新电梯的任务,也交给了调度器。
由于没有自己设计接口,接口分离原则无法实现或者没实现。
(4)自己bug与别人bug
这次最大的bug在于中止判断。三个电梯,必须等待所有人运完才可以停止,因为如果电梯有人需要换乘,但是其他电梯以及关闭的话,就会出bug。
本人在课下被这个bug卡住,也想去hack其他人,但是失败了。
除此之外,针对新增电梯的hack,也没成功。
总结与感悟
经过第二单元学习,对于多线程,线程同步,线程信息交换等概念都有了一定程度的掌握,多线程是一个重要的技术,但是也带来各种各样意想不到的问题,不单单是程序本身逻辑问题,各种不确定性也会带来各种问题。这一单元的学习中,学了各种手段来对抗不确定性,最大程度的发扬多线程的优势,减少他的问题。