oo第二次博客

 

一.第五次作业

类图：

度量分析图：

时序图：

 这次作业是电梯系列作业的终极版，要求是使用多线程实现三部电梯的运行。

这次作业的难点在于第一次运用多线程技术（我之前作业采取的是扫描指令队列预先判断电梯行为，而电梯类无实际作用，导致这次作业要重新设计）。

二.第六次作业

类图：

度量分析图：

时序图：

 

 

 

在这次的作业中，对于从控制台输入的IFTTT请求，创建一个相应的监控器，每个监控器对应一个线程，而线程之间共享的资源为监控的文件。

各个线程需要获取文件信息，对文件进行修改等操作，如果多个线程同时修改一个文件，就会出现线程不安全的问题。

针对于这个问题，需要设计一个SafeFile类，此类中包含对文件的各种操作，并且通过锁的方式将各个有可能造成线程安全问题的方法锁起来。

每个线程对各自的监控范围进行扫描，并将信息与已有的信息进行对比，如果发生了线程对应的监控操作，则进行相应的操作。

三.第七次作业

类图：

 

度量分析图：

时序图：

第七次的作业是模拟城市中，对于出租车相应请求的程序，是出租车系列作业的第一次作业，主要是模拟在城市地图中，若出现请求，调度器将按照一定的规律将请求派发给相应的出租车。

对于100个出租车，每个出租车为一个线程，各自互不相关的工作。对于请求，我的做法是将输入的请求以队列的形式储存，先判断请求执行的对应出租车，然后将这条请求归入相应的出租车线程，同时实现输出。请求类中包含有请求的目的点与发出点。线程每隔大约100ms对所有出租车进行扫描，查看若有符合要求出租车，即加入抢单队列。

在100辆出租车上加锁，解决线程不安全的问题。

心得体会

这三次作业的难度很高，由于引入了多线程机制，导致许多的bug不可复现，也因此增大了找出bug的难度。

不能再完全依赖与数据测试寻找bug，需要阅读代码来进行bug的寻找。

尽量让每一个类中的数据均有获得返回值的方法，这样在实现新的功能时就很容易引用之前的方法中的数据。

因为这几次作业总体很大，其中蕴藏许多细节上的问题，不能完全规划好自己的思路再进行代码编写。走一步看一步会比较好。

在代码量变大之后，规范代码风格就变得十分重要，不然给自己的debug过程造成很大困扰，每解决一个问题就需要添加一个变量，从而导致了god类的出现。

希望自己还能活下去。