xmk233 / elevator-distribution-als Goto Github PK

输入的格式：(FR, n, UP/DOWN, t).(ER, n, t)，在一行中输入，每个请求之间都由‘.’隔开，结果会分行输出
输入的格式应为如上。。

可能有的限制：
1. 如果有一系列相同请求时间相同，会被当作是不合法的输入，无法进行电梯调度。各条指令发出的时刻必须各不相同且单调递增。
2. 该程序最多只取99条指令，如果其中有错误的指令，会被删除，真正处理的指令数可能不到99个
3. 输入的原始数据长度不能超过3000个字符,否则直接不予计算报错
4. 输入的所有数字数据必须都是int类型的整数
5. 输入空指令报错
6. 输入的单个数据包括前导零在内不得超过6位整数，否则当作输入不合法，不予计算直接报错
7. 哪怕仅仅是一个单项式中有格式错误都会导致出现不合法输入的错误，所有其他的有效指令都不予计算
8. 认定初始的时候电梯是空的，在1层，所以第一条指令必须是FR指令，否则该指令被删除直至第一条指令是FR为止
9. 我所定义的输出是这三种解释：n是停下的层数；方向是指：停在这一层之前是什么运动方式，就是以什么运动方向来到本层的；如果指令不导致楼层的变动，就保持原来的状态，up还是上一个up，down还是上一个down；t是指到达这一层那一瞬间的相对时间（不包括开关门的时间），初始时零。初始时的电梯状态会以(1,DOWN,0)的形式输出。
10. 电梯如果停在某一楼层，就会做一个完整的开关门动作，然后保持关门状态。当然，最初始时门是关着的。
11. 为了安全起见，如果电梯到达某楼层后0.5秒在同层楼发布FR指令，如果乘客想趁停在本层的时候进去，对不起，不得进入。因为留给乘客的时间不多，从停止到开关门统共就一秒，考虑到先下后上，等下电梯的人都下去了，准备在该层楼上电梯的乘客过了半秒钟才想进去，太晚了，门准备关了，强行进去的话一不小心就容易被门夹到，不安全。所以必须将该FR指令当作下一条命令执行。
12. 所有的问题都共享以下前提：发出FR指令的人未必都会进电梯，发出ER指令的人未必出电梯，但是初始状态的时候电梯里一定没有人，不可能发出ER指令；无论到达哪一层停下，电梯都会进行一个开关门的动作，用时一秒；
13. 楼层为负、楼层的数字有三位以上数字、时间在6位以上等会被认为是输入不合法，无法调度。
14. 在不影响正确性的前提下，所有的输入空格都会被清除
15. 每一次合法输入都会对应有一个输出
16. 空的指令会导致无法调度电梯
17. ^(((\\(FR,\\d{1,2},(UP|DOWN),\\d{1,6}\\))|(\\(ER,\\d{1,2},\\d{1,6}\\))).)*((\\(FR,\\d{1,2},(UP|DOWN),\\d{1,6}\\))|(\\(ER,\\d{1,2},\\d{1,6}\\)))$是合法输入的正则表达式，违背这个表达式的输入都被认定是无法调度电梯的。
18. 如果输入的所有的指令都是错误的指令，（比如在10楼按UP，第一条指令是ER并且一直都是一直都在被删除等），最终会导致输入不合法，不予调度。例如(FR, 20, UP, 0).(ER, 10, 5).(FR,15, DOWN, 1596)。
19. 本程序支持第一条指令不是从0时刻开始的。不过按照实验要求，最好不要这么做。但是，若输入的部分请求有错误被删除，导致最后可执行的命令队列中第一个指令的命令时间并非为零，计算出结果后，并不算是程序bug也不能算是程序逻辑有误。
20. 楼层如果为负数，认定为是非法输入，不予调度电梯。
21. 因为采取了捎带机制，所以同时发布的请求某种意义上不再是不合法的时间序列。但是本程序不做容纳同时发布请求的取舍处理机制的扩展，所以同时输入的请求依然被认定是不合法的时间序列。在这里认定，时间按照升序排列的请求依然符合非降序的要求，升序属于非降序。
22. 从现在开始认定，FR指令中的方向是有意义的，至少在判断是否顺路的时候是有意义的。比如不要指望在某层楼按了向下的按钮后，上行的电梯还会顺便搭上你。主请求如果是FR，FR的上下不代表进入的人一定会向上或向下。
23. 如果电梯是静止的，则接收到的第一个请求就是当前主要请求，不接受反方向的请求。
24. 当前主响应请求完成后，如果没有紧接着处理的下一个主响应，哪怕再方便，电梯也会优先处理未处理队列中的最开始的那个，将其作为下一个主响应请求。例如主响应请求是到9层，未处理的请求中第一个是下到2层，第二个是上到10层。那么本电梯会在处理完到达9层的响应后处理下到2层的指令，随后再处理到达10层的指令。
25. 作业2中的程序说明曾解释了电梯中最开始不能有人，请求序列最开始的时候不能是ER，所有的开头的ER会被删除。但是，由于有了捎带机制，所以可能出现在傻瓜调度下符合事实逻辑的指令变得看上去不再符合之前定义的事实逻辑。所以，事实逻辑变更为：最开始的时候电梯中可能有人，但初始的请求序列依然不得以ER开头，否则将删除开头的ER直到开头的是FR指令为止。（强行解释）。
26. 如果一个主请求完成了，但是有可能有捎带请求没完成，这个请求中的第一个就会成为下一个主请求。但是在本程序中，如果这个未完成的请求是ER，则这个ER不会进入到它之前的主请求队列中的从请求中。它会直接成为下一个主请求。
27. 第一个合法请求肯定是FR类，并且第一个请求楼层无论是几层，输出方向都会改为UP。
28. 更新：输出的时间序列，之前定义的最开始有一个(1,DOWN,0)不会再输出了。
29. 更新：最终输出运行结果序列的时候是有方向如果在同层不变，不输出这一项。
30. 在运行过程中恰好经过某层楼时，发布ER、FR同层请求，电梯将不停止。即不能急停。
31. 继承机制用在了Dipatcher1里；interface用在了Status上；toString在Dispatcher1中，用于将一个ArrayList生成为String。本程序中某些类中为了方便，在不影响功能实现的前提下使用了部分共有属性，基本法里并没有限制本次作业的共有属性的使用。
32. 如果在电梯停住的后0.5秒发布同层打开电梯的请求，乘客不得入内，电梯不予捎带这样的请求。
33. 每开一次门就输出一次，时间是开门前的一瞬间的时间.
34. 在某一层停下，开关门（1S）后在当层发出的请求不会被认为是捎带请求。
35. 在某一层停下，这一瞬间发布同层楼的请求，会被捎带.
36. 输入格式不变，输出为1、请求列表，格式是（Primary_request）（（carrying requests1）（carrying requests2））。（Primary_request）（carrying requests1）就是输入的样子，捎带请求放在括号里，中间没有括号隔开。2、按照时间排序的停靠时间和方向的表。
37. STAY状态是本次程序新增的。只有在主请求完成后，后来的主请求在同一层提出时才会出现。
38. 如果有一连串同层请求，那么他们都会被看作是一个个的主请求，除非它们是同时的才可能被捎带，然而本程序并不支持同时请求。
*不予计算，报错，直接报错，输入不合法等字眼被认定是无法进行电梯调度  

可敬的兄弟/可爱的菇凉：
	鄙人尽力完成了本程序的设计和调试。
	如果阁下发现了本程序的错误和疏漏，一定不要留情，您发现的错误对于鄙人在学习技术的过程中的进步和成长有帮助。千里之堤溃于蚁穴，在我日后可能酿成更大错误之前，这进一步探穴求错的过程就交由给阁下完成了。
	请不吝赐教。
	多谢/Thank you/ありがとう
									本程序制作人