第二单元总结

设计策略：

这一单元的三次作业我的程序基本上一样架构，主线程负责接收输入并传给CONTROLLER， 然后由CONTROLLER在接受乘客之后唤醒电梯，并负责将乘客传递给电梯。

结构比较简单，只有五个类：main，control，elevator，passenger，Globalvar。其中只有elevator类是线程。

elevator类是电梯，上下移动，每当电梯空的时候就向control来申请，control则按照调度方法告诉电梯应该去哪一层，这时如果所有楼层都没有乘客，就让电梯线程wait。直到新乘客来了再将电梯唤醒。

由于只有elevator类一种线程，产生冲突的情况仅有当几个电梯停在同一层同时上下乘客的情况，只要通过给每层的乘客arrayList加上锁即可解决。

这样的作法使得类的数量很少，但是相应的类里面的方法很多。

度量分析：

可以看到OCavg很低，这是因为很多方法都是仅有一行的，但是方法个数很多，这主要是因为类要实现的功能比较复杂，我通过增多方法个数来降低每个方法的长度和复杂度。

 

可以看到，方法基本上都是比较简单的，只有几个方法比较复杂，这主要是因为这些方法比较特殊，其即使拆分成多个方法，这些方法在其他地方并不会使用，所以没有多大意义。

 

可扩展性：

elevator类主要就是一个电梯的基本功能，其使用的control中的方法只有4个：一个是查看当前停的层是否有乘客要上带电梯，一个是从当前层获取一个乘客，一个是释放乘客到当前层，还有一个是当电梯空的时候，向control申请下一个乘客的所在层。

可以说elevator类和其他类的耦合度是很低的，尽管其内部各种方法很多，但是停靠层、类别等信息只需要更改globalvar里的内容，不需要对其进行更改。

passenger类是用来记录乘客的各种信息，包括id，目标层，出发层等。功能简单，耦合度低。

control类由于负责了从main里接受输入，应答电梯的请求，以及一些分配算法，所以是功能十分复杂，耦合度高的一个类。

如果需要降低耦合度，增加可拓展性，那么可以把control类的内容进行拆分，比方说调度方法可以单独出一个类。

 

BUG分析：

这次出现的bug一个是在第二次作业没有加锁，一个是第三次作业的一个细节错误。

第二次的bug很严重，是我疏忽了线程之间的冲突问题。第三次的bug属于代码的细节问题。

发现别人bug的策略基本上就是测试最基础的几种情况，比如只上一个人，一个电梯看程序有没有正常结束。

 

心得体会：

这次作业第一次接触了多线程，虽然最初被多线程的MonitorStateError折磨得很惨，搞了半天才弄懂。但是总的来说并不是很困难，一个好的设计结构可以避免很多bug。