第二单元博客总结

第一次作业

(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,也没成功。

总结与感悟

   经过第二单元学习,对于多线程,线程同步,线程信息交换等概念都有了一定程度的掌握,多线程是一个重要的技术,但是也带来各种各样意想不到的问题,不单单是程序本身逻辑问题,各种不确定性也会带来各种问题。这一单元的学习中,学了各种手段来对抗不确定性,最大程度的发扬多线程的优势,减少他的问题。

posted @ 2020-04-14 12:23  润羽るしあ单推人  阅读(269)  评论(2编辑  收藏  举报