oo第二次博客

第一次作业：总共两个线程，主线程(输入线程)和电梯线程，采用生产者-消费者的设计模式，主线程同样也是输入线程，负责将新的请求加入队列，电梯线程每次取出请求队列的第一个元素。如果队列为空那么电梯线程阻塞，有新的请求加入队列的时候唤醒电梯线程，从而实现线程同步；电梯线程和主线程互斥访问队列。
第二次作业：方式同上。
第三次作业：总共四个线程，主线程(输入线程)和三个电梯线程，采用worker-Thread的设计模式，主线程工作方式同上，但是主线程需要监视三个电梯线程，并且维护三个电梯的等待队列，同时当某个电梯线程完成某个乘客的一部分请求需要换乘的时候，将请求扔给主线程。由于每个线程都有自己独立的等待队列，所以线程的同步与互斥仍然采用第一次的作业的设计方式。基于度量

基于度量的程序结构分析

三次作业的设计架构一脉相承，只是调度器的策略略有不同，所以给出第三次作业的分析，来代表这三次作业的结构情况

通过一个请求的执行过程来解释上图的结构：

调度器对象是主线程和电梯线程共享的对象(通过单例实现)，主线程通过读入请求，调用调度器的put，调度器根据一定的策略将对象放入队列

第一次作业和第二次作业都是直接将请求放入等待队列
第三次由于三部电梯的功能不同，调度器中维护了三个等待队列，以及一个共享等待队列。调度器根据请求的楼层来放置请求，如果fromfloor只有某一部电梯可以到达，那么就直接放入这部电梯的等待队列中；如果该请求是一个可直达请求，就放入能直达的且任务数最少的电梯的等待队列中，从而实现负载平衡；其他情况，就放入三个线程的共享等待队列中，让三部电梯来抢夺请求。

第一次中不含有捎带，只有线程的同步互斥，已经做过分析。这里继续来看第二次和第三次的作业中电梯的行为

对于一部电梯而言

通过调度器的peek方法来获取等待队列第一个乘客的请求，来确定电梯的初始行驶方向(set Direction)
通过判断请求的运行路线，来确定电梯是只需朝某个方向运行，还是需要折返
执行tofloor()即沿着设定的方向到每层查看有无乘客上下电梯（hasPassengerIn, hasPassengerOut)，如果有就执行(PassengerIn, PassengerOut)，先下后上。直到从当前楼层到最远楼层都没有请求（请求方向与电梯的运行方向可同可反)并且电梯中也没有乘客，那么电梯暂时停止。如果在2中确定需要折返就折返，不折反就still，停住就好。这里了仿照扫描算法
完成一次往返并到达still状态，叫做一次proceed。

LOC (Lines Of Code – at method and class granularity)

代码行数，可以看到你的方法和类写了多少行。
CC (Cyclomatic Complexity – Method)

圈复杂度，用于衡量一个模块判定结构的复杂程度，圈复杂度越大说明程序代码质量低，且难以测试和维护。
PC (Parameter Count – Method)

方法中传入的参数个数。
NOF (Number of Fields – Class)

类的字段个数。
NOPF (Number of Public Fields – Class)

类的公共(public)型字段个数。
NOM (Number of Methods – Class)

类的方法个数。
NOPM (Number of Public Methods – Class)

类的(public)型方法个数。
WMC (Weighted Methods per Class – Class)

类的加权方法个数。具体加权算法怎么算，笔者不太清楚。
NC (Number of Children – Class)

类的子类个数。
DIT (Depth of Inheritance Tree – Class)

类所在的继承树深度。
LCOM (Lack of Cohesion in Methods – Class)

方法的内聚缺乏度。值越大，说明类内聚合度越小。

电梯的上行与下行的时间这里我直接写的，导致Magic Number，下次需要改进；内聚不够

代码行数均衡，复杂度适中

第一次就是生产者消费者，时序与第二次相同，只是不含有捎带，可以参见第二次的UML

SRP：符合，每个类和方法功能单一。

OCP：不符合，由于第一次的情况较为简单，所以队列直接使用了BlockingQueue

LSP：没有使用继承，无法判断。

ISP：没有使用接口，无法判断。

DIP：不符合，由于第一次作业每次只上一个人，直接get就好，但是之后几次作业中都是要求返回队列中的一些元素，所以需要改变参数和返回值