OO第二次博客作业--第二单元总结

第一次作业

1. 设计策略

第一次作业，一共三个线程，主线程、输入线程和电梯线程，有一个共享对象--调度器（队列）。

调度的策略大多集中到了电梯里，调度器反而只剩下一个队列。

2. 基于度量的分析

类图：

方法复杂度：

如上所说，调度的策略大多集中到了电梯里，导致电梯的run方法复杂度大大提升。

类复杂度：

solid原则：

Single Responsibility Principle (单一功能原则)： 基本满足，电梯、输入处理、调度队列的功能职责都只归属于一个类。

Open Close Principle（开闭原则）: 不满足，扩展性较差，电梯的调度策略都在电梯里，上下楼的方法用的是累计，然后sleep（楼层数 * time），无法动态地检查每一楼层。

Liskov Substitution Principle（里氏替换原则）： 满足。本次作业除 extends Thread 外没有涉及到继承关系。

Interface Segregation Principle（接口隔离原则）： 满足。本次作业没有涉及到接口。

Dependency Inversion Principle（依赖反转原则）： 满足。

3. 程序的Bug分析

第一次作业逻辑比较简单，所以在强测和互测中暂时还没有发现Bug。

4. 互测策略

由于本次作业比较简单，我在互测中同学的代码中没有发现线程安全相关的问题。在互测中主要靠读别人的代码，发现一些细节上的、功能相关的问题，比如顶层和底层的限制等。

第二次作业

1. 设计策略

第二次作业的要求是在第一次作业的基础上添加了地下三层和ALS可调度策略，要求我们不再一次只载一个人，而是做得更像我们生活中的电梯，更真实效率更高的电梯。

我的架构大部分沿用了前一次作业的设计，仍旧是四个类，三个线程--主线程、输入线程和电梯线程。其中输入线程和电梯线程共享一个对象--调度器队列。

其中调度器仍然只充当一个队列的角色，只负责存取乘客的信息，大部分的调度的策略都被我写在电梯类里。

而电梯的调度算法没有使用指导书推荐的算法，而是使用了一个电梯的经典算法--Scan算法。

2. 基于度量的分析

类图：

方法复杂度：

其中 Elevator.need() 是检查 ”是否还有继续在这个方向上运行的必要“，检查后若没有必要则掉头。

这两个方法耦合度较高。

类复杂度：

电梯类承载了太多调度的策略，导致复杂度较高。

solid原则：

Single Responsibility Principle (单一功能原则)： 不满足。电梯类不仅承担了电梯运行的指责，还承担了调度的指责。

Open Close Principle（开闭原则）: 不满足，扩展性仍然较差。电梯的调度策略都在电梯里，无法拓展到多电梯。

Liskov Substitution Principle（里氏替换原则）： 满足。本次作业除 extends Thread 外没有涉及到继承关系。

Interface Segregation Principle（接口隔离原则）： 满足。本次作业没有涉及到接口。

Dependency Inversion Principle（依赖反转原则）： 基本满足。

3. 程序的Bug分析

本次作业中我的程序里没有发现功能上的Bug，但存在性能上的Bug导致实际运行时间过长。

我的调度策略是，在电梯为空时接第一个人，然后以第一个人的方向开始运行。这种调度方式会导致接完第一个人后，去接的那个方向上的以后的人都会被忽略。

如图样例，当第一个请求出现，电梯会先去接第一个遇到的请求，接了之后立马会把方向转化为他想去的方向，即接到第一个八楼的人会立马往下运行，而九楼及以上的人都接不上。如上的样例需要来回送九趟……

4. 互测策略

与上一次作业差不多，主要检查一些功能上的细节，捎带的功能检查等。

在讨论区看到了一个大佬的自动测试，替换掉官方的输入输出接口可以直接在输入中加入时间，实现自动定时输入。

第三次作业

1. 设计策略

第三次作业的难度对于前两次作业总是一个飞跃，增加了两部电梯，每部电梯的可停靠楼层、运行一层的时间和最大载客量都不同。三部电梯之间的差异就决定了这一次我只能重构。

这一次作业我的程序有五个线程，主线程、输入线程和三个电梯线程。三个电梯线程和输入线程共享一个调度器对象，输入线程负责将请求放进调度器，然后调度器根据请求的起始楼层，结合三部电梯的运行状态，将请求拆分或者直接放入某部电梯的等待队列。

而在拆分请求的执行先后顺序控制上，我建立了三个个数组，分别保存了三部电梯等待人员ID和是否经过拆分，若经过拆分则不能接，然后每次送达都检查一次这个数组，更新数组。

2. 基于度量的分析

类图：

整体构造和上次一样。

方法复杂度：

方法复杂度显示出 Elevator.need() （检查是否有必要继续向现在的方向运行）和 Elevator.run() 耦合度较高，判定结构过于复杂。同时 RequestManager.addRequest(PersonRequest) 方法（尝试拆分请求并分发到电梯的等待队列）复杂度过高。

类复杂度：

由图可知，Elevator 类和 RequestManager 类之间耦合过高。

solid原则：

Single Responsibility Principle (单一功能原则)： 勉强满足。电梯、调度器、输入都只承担了自己应该承担的职责，但电梯、调度器的职责还是太过复杂。

Open Close Principle（开闭原则）: 满足，具有扩展性。

Liskov Substitution Principle（里氏替换原则）： 满足。本次作业除 extends Thread 外没有涉及到继承关系。

Interface Segregation Principle（接口隔离原则）： 满足。本次作业没有涉及到接口。

Dependency Inversion Principle（依赖反转原则）： 基本满足。

3. 程序 Bug 分析

与上一次作业一样，功能上没有bug，而因为性能太差产生了 bug，特别的是这一次的bug与上次是同一个bug，错在同三行代码，名副其实的祖传 bug。

4. 互测策略

在这一次作业的互测流程中，我主要运用了大佬分享的自动测试包，对我的和互测屋里的同学的代码进行测试，结果比对，命中率不算高（可能由于评测机不太稳定？）。

心得与体会

第二单元的作业感觉除了关于处理线程安全和多线程调试的问题，总体比第一单元更好写，更不容易出错。

而要处理好线程安全，我们可以直接使用线程安全的数据结构，也可以在设计上处理好wait, notify 和锁的关系避免出现bug。

设计原则上，我们需要在设计阶段就考虑单一功能原则和开闭原则，避免写出不可拓展的代码，或者耦合度过高的代码。