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这门课的锻炼与批评，希望自己能够在接下来静下心来认真学习新知识、多思考、多发现问题，提升自己。