OO第二单元作业博客

1.设计策略

第一次作业需要实现一部简单电梯的运行。我选择将本次作业的三个部分，读入数据、数据存储与分析（system类）、电梯运行。其中读入数据的线程就按照提供的接口使用方法顺序读入即可。电梯线程实现上下行、开关门操作，具体进行什么操作由system类决定。这里system类我并没有将其设置为一个线程，而仅仅是实现了数据添加删除查询以及分析的方法，而输入类与电梯都可以调用这些方法。其实这就是work-thread模式。到了第二次作业，需要实现多部电梯的运作，而且添加了加入电梯的操作。这其实与上一次的变化不大。我做出的改变仅仅是重写了电梯的调度方法。到了第三次电梯的种类做出了限制，那就是说可能对一个乘客来说要经历换乘才能到达目的地。这里我为了不改变自己的架构，选择将判断工作交给乘客去做。也就是设置了一个pasagge类，它可以根据自己的所在楼层和目的楼层来判断自己应该坐哪一部电梯以及坐到哪一层下。这样的话对调度算法改变就不多，因为乘客自己会决定如何坐电梯，到达后如果换乘就视作新乘客就好。所以对我来说，第三次主要工作是写乘客决定楼层的判断逻辑。

2.拓展性分析

这个设计模式的核心方法就是system类的analyse方法。它就是通过现有的数据分析一部电梯的下一步的运动方向。如果只是增加电梯，需要做大变化的就只有电梯调度分析方法，这样可拓展性其实就还可以。第三次作业我为了防止system的功能太集中，就使用了passage类来选择如何乘坐。但这样做拓展性其实就不好了。一旦需要添加一个可以自定义到达楼层的电梯，我的方法就要重写。这些是调度策略的拓展性分析。而对于电梯本身，我认为拓展性是一直很好的。应为对于我这个设计，电梯要做的就是在每一层判断是否开关门，是否需要上下运行，而判断是由system的一个方法实现的。事实上这三次作业我都没有对elevator进行大的修改，仅仅是增加了询问它型号，名字的方法。这样来看除调度算法之外的部分拓展性都还可以。

3.程序结构分析

UML类图如下

                     

                                                                                     

度量分析

 

elesystem实现了大部分的功能，但它不是一个线程。

 

  

elevator总体上逻辑很简单，只是run方法使用了很多system的调度方法。

实际上最复杂的方法就是实现乘客判断如何乘坐电梯。

这是第三次作业的度量分析。事实上三次作业的结构变化不大，只是第三次作业需要对person类实现判断方法。可以看出system类较复杂，就是因为所有的数据存储，分析等功能都是它实现的。这其实是我的设计的一个缺陷。过于集中的逻辑在进行迭代开发时很可能会需要进行很多可以避免的修改，甚至可能要对整个类重构。

4.bug分析

电梯作业出现bug大致就两种，一种是调度方法错了，一种是涉及到多线程安全问题。第一次没有出现bug。事实上第一次主要是电梯的调度算法比较复杂。从多线程角度来看，有关线程安全问题只有输入类添加数据和电梯读取和删除乘客信息，只要使用synchronized方法修饰system类就能很好。第二次出现了一个因为设置了多个输入类导致的bug，这并不是一个很复杂的bug,它的修复是比较独立的。到了第三次我被hack成功了一次，具体错误我并没有成功复现。但是我查看我的强测数据发现自己的cpu时间有点高，全部超过了4秒。我分析了一下，发现是因为第三次作业我为了防止发生死锁，在system类力一些不必要的方法的末尾加了notifyall()。这样做就会重复地唤醒不该唤醒的电梯线程。我去除了那些不必要的notifyall()后所有的CPU时间又变回了两秒以下，而且bug也修复了。我想那个hack成功的数据应该是因为CPU时间太长导致了一些错误。

5.总结

在这一单元，我了解了java的多线程设计和线程安全问题，还认识了生产者-消费者、Worker-Thread、订阅-发布等设计模式，让我明白了优秀的设计架构带来的高效的编码等诸多好处。由于我一开始就是使用了一个较好的架构，所以后两次作业主要时间花费在了电梯调度算法问题上了。不过在第一次作业，主要是在多线程方面花费了很多时间，因为是第一次接触这个概念。总的来说，这三次作业让我获得的收获还是蛮大的。下一个单元我也会继续努力，学习好的方法与思想。