OO第二单元学习总结

一. 设计策略分析

  • 在多线程的协同和同步设计上,我的三次作业都通过使用共享变量对象中的synchronized方法来构成,与调度器交互的所有方法都锁起来,防止多个线程对调度器中队列等字段同时修改。

 

二. 设计原则分析

  • SOLID之SRP:

  在电梯线程类,我让其方法仅限于管理自己这一步电梯的行为,如开关门上下楼、选择方向;在调度器类,我让其处理了关于总等待队列和所有电梯等待队列的相关行为,如分配请求给某电梯队列、遍历队列检查捎带等。整体看来通过分层次达到了类的分工。

  电梯类中的方法分工有些不均匀,Cope方法承包了与调度器交互检查捎带、检查开关门上下人一系列行为,导致其负担过重,没有达到SRP原则的要求。

  • SOLID之OCP:

  在本次作业中,我没有使用接口,电梯和调度器都只有单一的类,通过实现接口的扩展方式是不可能的。

  如果有新的要求加入,可以很方便地添加电梯类的字段或方法,但由于其中Cope方法的复杂,极大可能性会导致修改。

  • SOLID之LSP:

  在本次作业中,我新建了两个类用来继承给定的PersonRequest类,不过因为没有添加新的属性或方法,仅仅是用来区分(instanceof)被拆开处理的请求,所以这一原则没有具体体现。

  • SOLID之ISP:

  由于没有在本次作业中使用接口,所以这一原则没有得到体现。

  • SOLID之DIP:

  电梯线程拥有调度器类(共享对象),调度器中的容器中又包括了电梯类。在调度器分配请求时没有与电梯内部状态的交互,但电梯获取捎带时与调度器有较深交互,造成不少依赖。


 

三. 基于度量分析程序结构

  • 第一次作业

UML类图:

 方法复杂度:

   建立两个线程Input和Elevator,托盘类Dispatcher作为共享变量,使用生产者消费者模式。捎带策略基本采用ALS,每到一层检查一遍是否有需要捎带的请求。可以看出,Elevator类的方法复杂度较高,与电梯有关的行为乃至捎带都由它完成,而Dispatcher类仅有最基本的Put、Get和判断结束方法,电梯自取需求,任务分配失衡。

  • 第二次作业

UML类图:

 方法复杂度:

   这次作业整体架构与第一次没什么区别,由于电梯可能有多部,若是仅仅使用第一次作业的电梯类中检查捎带,似乎会导致发生率不低的线程安全问题,我便更改了获取捎带的方式,捎带策略并没变。在每部电梯中草率地增加了wait队列,多部电梯在总体队列中随机抢要求加入自己的wait中,而且一抢就要抢够自己的容量除非已经没要求了,这一方式使得本次作业的性能极差。第一次作业中复杂度较大的方法在本次作业更甚,而且线程安全问题并没有通过我的方法得到真正解决。

  • 第三次作业

UML类图:

 方法复杂度:

 

   本次作业中,我稍微修改了架构,Dispatcher中通过容器管理各个电梯的等待队列,当有新请求到达时便直接在其中分配给各个电梯,无需电梯自己去抢,改善了线程安全方面的一些问题,而且分担了电梯类的捎带工作,平衡性有所改良。因为增加了可能的换乘,所以将要换成的请求拆分,通过继承PersonRequest类来区分,再增加一些判断就可以达到换乘的目的。捎带策略仍没有改变,只是为了线程安全整体移植到Dispatcher类。


 

四. 分析自己程序的bug

  • 本单元的作业中bug层出不穷。
  • 第一次作业中,捎带策略后上电梯的处理错误,导致已上电梯的乘客会重复登上电梯,互测和强测中都WA了几个点。
  • 第二次作业中,对乘客容量有限制,但乘电梯时重复判断,导致当排队的乘客超过容量时,所有人都进不去电梯,因此强测中WA了一个点。除此而外,线程安全的处理做的不好,导致出现问题的几率较大。互测中没有被hack到。
  • 第三次作业中,对需要换乘的指令的拆分没有做好,在某些楼层之间会换乘混乱导致错误;之前两次作业一直沿用的、也没有出现过问题的程序结束条件在这一次出现了问题,有的要求已经到队列了还没实现呢程序就结束了,导致最后几个人的要求达不到满足。互测和强测中都WA了几个点。

 

五. 分析发现他人bug的策略

  • 由于作业架构的灵活性,每个人的架构都大相径庭,因此我没有去仔细分析具体代码中的策略去寻找bug,而是通过我在写作业时发现的易错点手动构造有针对性地测试数据,如检测是否会超载、是否会因为捎带不完善导致超时等等。从简单的入手,逐渐提高数据的复杂度。

 

六. 心得体会

  • 这一单元接触了多线程,这真是一个充满玄学的领域,出现了好多次搞不清来源的错误,调试过程也让人十分苦手。
  • 本单元的作业我的分数都很低,基本都是我的疏忽与测试的不完备导致。虽然结果令人沮丧,但能发现问题也不算是坏事。我认识到自动化测试十分必要,花费一些时间去学习这一项能力比人工构造、肉眼debug的体验还是要好太多的。
  • 在完成作业的过程中还发生了个小插曲,因为自己未察觉到的失误慌不择路去讨论区发无意义的帖子,也给助教带来了麻烦,这对我是一个教训,出现问题时应当仔仔细细把可能导致的地方都考虑一遍,而不是质疑与依赖。
  • 总而言之,多线程的这一单元我收获到了oo这门课的锻炼与批评,希望自己能够在接下来静下心来认真学习新知识、多思考、多发现问题,提升自己。

 

posted @ 2020-04-18 10:36  Sentor  阅读(155)  评论(0编辑  收藏  举报