OO第二单元总结

摘要

　　简单概括一下第二单元，我认为难度相对低于第一单元，但是让我对面向对象思维和有了更好的理解。相对于第一单元的次次作业，次次重构，面向过程。在第二单元的后两次作业中，我开始能够做到伴随着作业要求功能的增加，难度的增加，不修改原本的代码，而是在原本的基础上进行添加。可以看出，在第二单元的学习后，我对面向对象程序的构架设计有了一个初步的认识。

 

OO第二单元第一次作业

 

　　这次作业的内容是一个傻瓜电梯。意在让大家初步了解多线程，单纯之论实现的话可以在1小时之内完成。但是第一次作业只是一个开始，需要的不仅仅是正确性，更需要有作业整体的设计。我OO第二单元的框架设计，就是在第一次作业中完成的。

 

　　下面是我的设计框架

---------------------------------------------------------------------------------------------------------------------------------------------------------

　　简单概括一下设计框架

 

 

 

 OO第二单元第二次作业

 

 　

 

　　相对于第一次的变化:修改了调度方式，第一次作业中只需使用傻瓜调度即可，但是在第二次作业中，作业要求大家必须使用捎带的策略。总的来说，就是调度策略的变化。

 　　个人采用维护两个请求队列，一个request变量：

 　　即dealqueue(电梯内人员)，inputqueue(电梯外人员)，mainrequest(主请求)，由于有了第一次的构架设计，这一次只需要修改电梯系统中子调度器的调度算法即可，其余部分不需要修改。

 

OO第三次作业

 

 

 　　纪老师口中的OO作业难度峰值，三部不同的电梯除了开关门时间相同之外，其余没有相同之处。

 

　　但是细看之下可以发现。三部电梯均可采用第二次OO作业的调度算法。又有可以扩展的框架设计，new出三个电梯子系统即可。再由主控制器对请求分发给特定的子调度器。因此主要的内容已经完成。下面只需要思考如何才能进行电梯之间的换乘，如何使电梯之间的调度更具效率？最优调度在请求仅有一条时，找到最优调度当且仅当等价于找到最短路径。而最短路径的计算，可以用大一下学期中的迪杰斯特拉算法便可以很容易的实现。

 

　　故而电梯之间的换乘的正确性可以通过迪杰斯特拉很轻松的保证，因此接下来我们来讨论效率方面的问题。

 

　　笔者是一个B组的佛系养生的菜鸡，找不出别人bug，别人也没有测出我的bug。按照讨论区dalao的提示写了评测机，但是依然懒得测，故而三次作业算在一起0 hack 0 被hack。

 

　　但即使是这样笔者依然希望有朝一日可以晋升到A组。由于摸鱼太久周二才开始动手，笔者最后没有时间进行优化了，就交了一个最朴素的版本上去。果不其然是B组（默默流泪）。

 

优化方式：

1.电梯的协作 例如 乘客从A->B 在B换乘，电梯C提前在B层等待或者说提前向C移动

　　优化方式，设置一个新的队列buffer，用于存储将要到达的指令，使其优先级低于正常的指令队列，因此当正常指令队列为空时，如果buffer中存在元素，那么在新的正常指令到来之前，电梯会向着buffer中的指令的起始楼层移动。

　　那么有人可能会问，如果在电梯向buffer中的指令的起始楼层移动时，突然出现了正常的指令，该如何处理？

　　在我看来，最好的解决方式，就是设置一个flag位，一旦正常的指令队列更新，便将flag置1，然后停止向buffer中的指令起始楼层的移动。开始优先处理正常指令队列中的指令。

 

2.最短路的选取

　　实际上，由于A,B电梯有着，速度较快，覆盖度广的特点，使用标准的突然算法处理的话，大多数指令会完全依赖于A,B电梯，因此很可能会出现A,B电梯负载过大，C电梯却空无一人的情况，无疑导致了资源的利用率较低。

　　优化方式：

　　模仿神经网络的方式，在每收到一条请求之后，通过每个电梯中人数的数量，电梯当前楼层，电梯运行方向。来修改图中路径的权值，使得3部电梯均能够被完全应用上。经过优化后，绝大多数情况都能比无脑取最短路快10%以上。

 

另：关于评测机的书写中的坑点

　　最简单的书写评测机的方式就是。多线程开启多进程以此同时测试7份代码。

　　坑点之一：分清进程的输入流和输出流(可能和你想象中的刚好相反.....嘤嘤嘤)

　　坑点之二就是flush，大佬也提到了。flush的作用是强制刷新。如果不用flush，就无法完成在特定时间做出特定输入，而是会变成，在程序的最后，一次性输入全部的指令。

　　只要注意以上两个坑点，评测机的书写还是比较简单的。