OO第二次作业总结

第五周作业

多线程

可以看到第一次作业基本上照搬了"生产者-消费者"模型，生产者和消费者共用了一个缓存区，缓存区中维护了电梯和走廊中的两个乘客队列以及其他属性。而我也在这次作业中确定了解决电梯问题的基本思路（这是完成了三次作业以后上帝视角的总结）：

首先电梯问题只有"乘客"、"电梯"和"走廊"三个对象，其中乘客的基本属性是"初始层"、"目的层"和"编号"，而电梯的基本属性则是"当前层"、"目的层"、和"乘客队列"，走廊对象则只包含一个"乘客队列"属性。

电梯问题的模型就是乘客对象依据自己属性依次进入走廊的乘客队列和电梯的乘客队列并在最后出队，同时电梯对象在读入的乘客对象以后修改自己的属性，最后电梯里的乘客对象依据电梯的属性和自己的属性出队的模型。

在确定了这个最最最基本的模型以后，三次的作业只需依据不同的题目要求稍稍增删一些属性和方法就能轻松解决。

 

度量

在套用了生产者-消费者模型以后可以发现多线程的代码平均复杂度非常低，仅仅有修改属性的方法和线程行为的方法复杂度稍高，后来我根据其中包含了解耦的思想。

自己bug

在确定了基本模型以后依照模型操作并未出现逻辑上的bug。

不过在调度方面，我利用了第一次作业电梯人数没有上限的这个条件，设计成了装入所有乘客再分别运送到目的地的方案（逃）存在被卡运行时间的隐患。

别人bug

人工阅读代码未发现同房大佬bug。

 

 

 

第六周作业

多线程

第二次作业中加入了每个电梯人数上限的限制，所以在电梯对象中增加了"人数"属性，同时在电梯读入乘客对象，使其入队的方法中加入了判断条件，其他的地方并没有进行太多改动。

度量

第二次的平均复杂的同样很低，仅仅是电梯读入乘客的方法在增加了判断条件后稍稍增高。

自己bug

在这次的程序中发生了申请两个的 "System.in"的事情（这居然是BUG！！？！？？？）导致我在强测里八个测试点都吃掉了第一个乘客（欲哭无泪PS：指被吃掉的人）（划掉）。。。

解决的方法是（抄J神评论区）只申请一个"System.in"并共享的操作（为什么没早看评论区）（划掉）。

别人bug

当然是阅读代码（在F房里提交指导书上的测试点都能hack成功）（划掉）。

 

 

 

第七周作业

多线程

经过了前两次生搬硬套的操作以后，我认为对多线程和OO的理解有了进一步的提高，同时本次作业中增加了不同电梯不同的"类型"、"人数"、"停靠层数"以及"速度"等每个电梯均不尽相同属性，我决对代码进行重构优化（其实还是生产者—消费者）（划掉）。

首先，由于这次作业中不同的电梯停靠层数不尽相同，所以在客观上增加了部分乘客对于换乘的需求，但是可以发现，每个电梯均在1层和15层进行停靠，所以本次作业在不考虑电梯性能的情况下均可以在一次换乘后到达目的地，但是事实上考虑性能的话也应该尽量换乘一次，所以换乘的操作其实是大大简化了的（同时我发现"走廊"属性的设置简直是提前解决了"换乘"这个需求）。剩下的大变化就只有在重构以后，将电梯对象从缓存区中分离了出来，确确实实新建了一个 Elevator 类。自此，我认为自己真正以OO的思想完成了作业。

度量

在重构以后可以看出来仍然是线程的行为以及修改对象属性的方法复杂度稍高，但是平均复杂度均有不同程度的下降（重构大法好。

自己bug

在经历了申请两个"System.in"的bug以后，这次竟然不需要这种操作了，所以在逻辑上并没有出现其他bug。

别人bug

阅读代码。。。（别骂了别骂了，我家里人都在看总结，你们别骂了，下次我手搓评测姬还不行吗）

 

 

 

第三次拓展

在同学们周三的分享以后，我发现不少同学在调度时候均使用总调度器，而我由于重构时间紧迫（根本没想到）仍然保留了每个电梯独立进行调度，这在事实上浪费了许多许多空置电梯的性能（测试点80分的凶手找到了）。所以如果有第四次作业的话我一定会通过增加总调度器来实现性能的优化。

 

 

 

心得体会

我认为这三次作业对我的提升非常大。不管是对于OO的理解，还是多线程的实现（还是敏捷开发）（划掉），（除了对头发和肝不太友好以外）（划掉）我给满分！！！