写在最前：

我我我我我我靠，以后再也不再ddl截止前1小时调试程序了！之前在DDL前1小时修改程序，当我改完后，我想着，再把之前的测试样例跑一遍，如果都对就OK了。就在这时，问题出现了，我之前正确的测试样例变成错误了。我心头一惊，想着会不会是哪里改错了。但是更恐怖的事情还在后面，我打开之后，我的输出是——没有输出！无可奈何之下，我先在本地测了一下，发现是正确的。同样的样例不止一个。很无奈之下，我又交了一次。更更恐怖的事情出现了，刚才错的对了！正当我惊喜之余，发现更更更恐怖的事情，刚才对的又错了。重复好几次，输出为空就像薛定谔的猫一样，随机出现。

我只能安慰自己，这大概是评测机的问题吧，挥手向DDL告别。

正文：

此次作业我们目标是实现一个单部电梯运行控制系统，电梯调度策略为先来先服务(FAFS)，与真实生活相比较为简单。接下来我将简单回顾下自己该项目的完成过程，力求再进行项目设计与实现时能够更加合理。

指导书阅读

在项目开发之前，指导书的阅读总是重中之重。在此次项目开发中，指导书的阅读同样占用了不短的时间——一个晚上的时间。

由于指导书本身较长，单通读一遍所花时间已经很长。往往发生的情况是读了后面的忘了前面的，必须要长时间阅读才能对所需完成的项目在任务目标和输入输出格式上有一个基本的了解。此次阅读中我采用了一种方法，感觉效果不错，那就是——笔记！在阅读指导书的同时将要求按照自己的理解进行重新编写，一方面帮助自己更好地理解项目，同时也大大缩减了书写readme的时间。(更为具体的阅读指导书的思路就暂时没有了)

类的构建及相互之间的关系

在进行电梯系统设计时，由于需要将任务分割为多个对象进行分别设计，那这些不同的对象之间如何交互便显得尤为重要。此次电梯控制系统需要设计的主要类有五种，电梯，楼层，调度器，请求队列，请求。在设计之前，首先需要明确五个类各自的功能。

请求类是信息传输的数据包，该类作为信息单位来承担类与类之间交换的责任。电梯由实际状态和电路两部分组成。楼梯有获取上下行请求的需求。电梯与楼层将请求发送至请求队列，调度器获取请求对电梯进行调度。

关键的问题是类与类之间如何交互？

我们当然可以将交互信息放在主函数中，但是这样在该系统中主函数便是一个信息传递的中心，与我们希望实现一个半封闭的电梯系统背道而驰。我们更希望类本身之间能够进行相互访问。想要相互访问，我能想到的方法便是让某些类的对象引用作为属性存在于其他类中。

再结合需求分析，我采取了如下的类的结构关系：

调度器、楼层、电梯共享一个实例化的请求队列类，同时电梯也作为调度器的一个属性存在。采用这种方式实现类与类之间的交互

代码编写

当我回顾编写代码的过程时，总觉得有些哭笑不得。在构思清楚类与类之后，花费一晚上时间才构建并调试好各个类和一个输入的框架，实现了能够将正确的请求列队的操作。当我代码码到这一步时，从来不曾想过该如何实现电梯的调度。而真正开始思考并编写核心——电梯的运转逻辑，竟然只花了前者一半的时间。这样的时间差真让人无可奈何。