又经历的三次作业，对于面向对象的理解稍稍有些加深
- 第五次作业——多线程电梯
相比于之前的两次的简单电梯，这次作业的难度上升的幅度非常大，一开始甚至有些盲目，不知道从哪里去下手，最终决定按照第二次、第三次这样的步骤来，首先开始构建单部电梯的非捎带运行，这样首先就排除掉了很多的简单的错误，起码电梯能够正常运行起来，然后实现了三部电梯的非捎带运行，这时已经就会有需要进行调度的情况了，最终再加上捎带的判断。其实这次作业的主要难点在于对多线程的理解以及使用，毕竟只听了课还是有点不太明白到底需要干什么。这次作业只是简单的线程控制，请求线程一直在等待着输入，调度器扫描请求队列，如果发现还有指令没有运行，就把这些指令都判断一遍，看是否有电梯能够进行运行或捎带，然后sleep 1ms 避免一直进行扫描占用CPU资源。但是可能存在着正在进行这一次扫描的时候加入了一条新指令，这条指令可能需要等待下一次扫描才能发现，因此可能会有一些延迟。每个电梯内部也都有自己的一串指令，这些指令都是能够被捎带执行的。将这一串指令均运行完之后便能够再接受其他的指令。
度量：
能够发现圈复杂度，参数的数量以及嵌套深度都有点高，以后会想办法进行改进。
类图：
由于继承了上一次的作业，但是实际上并没有使用到任何父类的方法，因此省去了父类及其他一些没有使用的类。可见类图也反映出成员变量过多的问题，很多属性是初期考虑可能要用上，但是后来没有使用上也没有删去的残余属性。
时序图：
这次作业的其实难点在于多线程，而捎带、同质这些的判断在之前就有过经验，所以不是很困难，第三次作业由于捎带条件没有弄懂而出了些问题，这次算是看明白了，但也有个小问题，就是没有考虑到捎带指令时也需要选择运行步数最少的电梯，这属于考虑不周，而测BUG时也是很无奈，按照自己的思路测试了各种情况，最终也没有发现什么错误。
- 第六次作业——IFTTT
有了上一次的经验，这一次就好了很多，重点是明白这次作业的目的到底是要干什么。输入一个地址后将其分配给对应的触发器，然后每隔一定的时间扫描当前触发器所需要监视的目录，找出发生了变化的文件再对其进行操作。理解明白之后就比较简单了。但是这次的重点是线程安全，比如同时写入等，因此构建了SafeFile类，简单粗暴的将各种方法都加上synchronized，虽然极大的拖慢了速度，但是在当前阶段也不是不行。
度量：
依旧是圈复杂度及嵌套深度有点高，以及存在大量的静态方法和静态变量。
类图：
四个触发器拥有大量的相似成员变量和方法，其实都可以继承一个触发器类，只是有点懒......不想去实现就直接建了四个。
时序图：
但是这次作业可能是对于操作的理解不同，对于SizeChanged类型的理解，我自己是认为只考虑输入指令时已经存在的文件的变化，即使是输入的目录，也是考虑输入时的目录里的所有文件，如果这些文件大小没有变化的话就不触发，而忽视新多出来的文件以及目录，这种想法可能和作业要求和测试者的想法不太一样，导致对于新增空目录以及新增文件这个一地方被测试者挂了公测，还被报了BUG，而公测那里明明说明可以不触发，测试者按照讨论区的要求来说必须要触发，各种地方的描述都不一样，可能这一点就是课程需要有点改进的地方，毕竟这种地方最容易产生冲突，尤其是指导书不明确。而我在进行公测时发现被测试者存在着很大的问题，经常出现莫名其妙的结果，比如重复输出summary，不生成detail文件等，根据分支树来进行测试。
- 第七次作业——出租车
出租车的作业相比上一次起码目标明确了很多，就是实现出租车，实现接客，送客。目标明确了，代码的编写稍微轻松了点。
度量：
看得出来依旧是老毛病，分支过多，嵌套过多。
类图：
这次的类图就清楚了很多。
时序图：
这次作业中也存在着一些问题，比如仅仅只是写了支持超过300条指令，但是自己并没有去测试，同时由于一些前阶段的残余代码没有处理，和后来输出的信息格式不太一样，被人报了BUG，以及没有考虑到出发地和目的地相同的情况。同时真心觉得这种互测存在一定的弊端，根本就没有弄懂别人的想法，完全靠着自己的想法去测，一切为了加分，不择手段甚至还想着和被测试者达成交易去让根本没有通过的公测点通过来让自己报BUG加分，可能这就是互测吧，人心险恶，永远都不知道测试者有多恶心。自己测试BUG时则是按照分支树，以及自己在撰写代码时所遇到的一些问题去写，发现被测试者表面上处理了同质指令，实际上并没有处理，并且对于出租车的信用度设置存在问题。
心得体会
1. 使用多线程时要注意线程安全，防止产生一些意想不到的错误。
2. 撰写代码时小心谨慎，写好注释，免得又遇到不想看代码，懒得去思考别人的想法的测试者。
3. 自习阅读指导书，思考可能存在的问题，最好做到提前想好解决措施，对于解决措施也一定要自己再测试一下，防止出现表面上处理了，实际完全没处理的情况