三次作业来的设计策略及其变化
这三次作业的重点就在于多线程，出租车、IFTTT、电梯，在不同方面去理解多线程的使用。其中主要是同步异步、线程间信息的交互和共享、锁和时间关系。此外还有依然重要的类的封装，也是面向对象的主要内容了。依旧以程序架构设计本身为主，思考多线程的实行，去思考和执行设计策略。再然后是测试接口，学会了去提供测试接口、使用测试接口、在别人的测试接口上写测试函数。
作业分析
第六次作业IFTTT整体设计思路：
1.为了减少大规模读取文件属性的代价，程序动态维护一个目录Map，其中保存了在上一个时间点文件的相关信息。对于每一个监听者线程而言，每次判断只需要从Map中拉取相关的数据即可。对于监听者和Map的关系，最初考虑使用观察者模式进行实现，但这种模式对线程自身信息的反馈支撑有所不足，所以选择线程按需拉取信息。
2.IF ** THEN ** 操作使用动态数组选择函数，最初看指导书认为可以对一个文件绑定多个检测函数作为一个线程，所以对每一个监视线程定义了全部的操作，根据需要在一个动态列表中对相关操作进行绑定。后来发现每一个触发器对应一个线程，所以可以考虑使用装饰模式进行触发器和任务的动态绑定。
3.安全读写类的实现。File类的问题在于他是非阻塞式IO，所以需要将其变作阻塞式IO，然后进行线程同步即可。
第七次作业出租车调度设计思路：
1.系统简述
此系统为出租车调度系统，主要对已初始化的100辆出租车按照一定规范进行管理和调度。从用户层面来看，需要在用户发出用车请求3s后按照信誉度，距离用户位置等信息进行综合排名，选定最优的车辆接送用户到指定地点。对每辆出租车，需要保证自己各时刻都处于运动状态，有机会参与更多的请求应答，提高自己的信誉度。同时，对每个有效响应请求，都需要记录相关的信息。系统主要存在的问题是出租车事务处理的延时和自身运动改变的时间窗口的冲突关系。举例而言，对每个出租车，其行走一条边的时间为200ms，那么出租车自身的事务处理（比如状态转换，路由等）必须低于200ms。GUI界面的更新应较为平缓，不可出现跳线的操作。
2.交互分析
与系统有交互的对象应该有三类：出租车，请求队列，相关信息记录类。对出租车而言至少应保证有唯一识别号,当前位置、当前状态、信用度三个属性。对请求队列类而言，至少应包含一个请求带有的全部信息，即：请求位置，请求时间，目的位置.对输出类而言，需要指明输出到的目标文件。出租车管理系统对出租车自身进行调度,负责更新出租车的信息和完成相关的调度任务,主要包括以下方面：1.每隔200ms, 更新出租车的位置信息；2.根据出租车当前状态,对出租车状态信息进行更新；3.对满足一定条件的出租车,分配接客任务。出租车管理系统响应请求队列类中的相关请求，在一个时间窗口结束后选定满足条件的出租车将其信息反馈给管理系统。输出类主要用于记录管理系统触发的一些操作，比如用户发出请求后符合条件的出租车信息，最后时间窗口结束后出租车的信息和最终根据条件选择的出租车编号。实际实现时增加了更多的类用于责任分流和松耦合。
3.并发分析
系统中的并发行为主要包括以下几个方面：
1)车租车自身状态的更新，对每个出租车其自身状态和位置的更新需要同时在较短的时间内完成，不允许存在较大的延时。
2)出租车自身位置与请求完成后选车过程的并行。
3)向输出类输出关于请求的相关信息。
从这三个方面考虑，在进行并发设计时需要考虑以下因素:
1)出租车位置的更新和获取需要进行同步，以防获取过程中信息的改变。
2)出租车状态更新的时延尽可能较小，防止对其他出租车的更新产生阻塞。
3)出租车状态的改变只能通过一个阻塞式的方法进行改变，防止多个状态改变引起出租车的运行错误。
4)进行相关信息记录时，不应该因为具体的操作而阻塞出租车的正常运行。
Bug分析和心得体会
在这段时间的作业中，主要的一个内容在于为测试者提供测试线程和使用测试线程来测试bug。这重申了面向对象代码封装的概念，以一个接口去测试整体程序。此外主要被提出bug的地方还是因为时间紧张带来的细节问题，并没有整体思路上的错误。所以在这段时间作业中，提前思考程序思路、多线程构造、想清楚再下手，以完善程序架构为主的重要性就被体现出来了。