OO第二次博客作业

引言
第一次电梯作业
第二次电梯作业
第三次电梯作业
Bug分析：
- 强测环节
- 互测环节
此阶段作业的收获与展望

引言

面向对象程序设计第二阶段的三次作业已经结束。此阶段的三次作业均是基于目的选层电梯的电梯系统设计，也是第一次关于JAVA多线程的阶段性作业。

第一次电梯作业

作业简介

基于先来先服务调度策略控制单部电梯进行人员运送。在评测中有时间限制，但无性能要求。

设计策略

线程模型：生产者-消费者

共享对象

第一次作业中，有两个线程——请求输入线程、调度器线程，输入线程与调度器线程共享一个电梯请求队列，用来同步消息。电梯此次并未被设为线程，而是被调度器直接指挥。这次作业使用的是生产者-消费者模式，输入线程作为生产者将用户请求加入请求队列，调度器线程作为消费者处理请求队列中的请求并根据请求指挥电梯运行。
线程安全的容器：阻塞队列
在此次作业的第一个版本中，笔者使用的容器是List。因为List不是线程安全的容器，笔者在对容器List进行添加、访问、删除的方法中都通过synchronized来解决多线程读写冲突的问题。
但是对于java这种面向对象语言，有很多封装好且线程安全的容器可以让java编程者使用，通过查看选择了线程安全的阻塞队列LinkedBlockingQueue作为输入请求线程、调度器线程的共享容器。

对请求进行封装

为了在得到输入结束信息后，通知所有线程请求结束指令已经到达，笔者在此次作业中对请求指令进行了封装，通过标志位来判断当前指令是不是请求结束指令。其实这种封装可以，但没必要。在第二、第三次作业中这种封装被取消了。

public class RequestStruct {
    
    private PersonRequest oneRequest;
    private boolean status;

    public RequestStruct(PersonRequest oneRequest,boolean status) {
        this.oneRequest = oneRequest;
        this.status = status;
    }

    public PersonRequest getOneRequest() {
        return this.oneRequest;
    }

    public boolean getStatus() {
        return this.status;
    }

}

调度算法：先到先服务

笔者在此次作业按照指导书实现了先到先服务调度算法，笔者在使用阻塞队列作为共享容器后，输入线程只需使用put方法将请求加入到队尾、调度器线程只需使用take方法从队首拿出请求。

线程间同步方式

使用阻塞队列实现线程同步

java线程同步方式有很多，譬如使用synchronized实现方法、代码块同步；使用特殊域变量(volatile)实现线程同步。但是上述举例中的同步方式都是在底层实现的线程同步，但是我们在实际做java开发当中，应当尽量远离底层结构。笔者在这次作业使用的是阻塞队列LinkedBlockingQueue作为线程共享容器实现线程间同步。

度量分析

复杂度度量分析

CK度量集分析

本次作业协作图

本次作业的类图

从类图、复杂度、CK度量集分析架构设计优劣

从类图上来看，类的关联是按照请求处理流来设计的，如此设计可以保证无多余的类间关系，但是在之后作业由于不同电梯处理请求的能力不同，请求处理流会出现分支，而此次作业的设计对于此类增加的需求可扩展性不强。
从上述的复杂度分析、和CK度量集分析此次作业的各个类耦合度不高，各个方法的圈复杂度也不高（自己在第一阶段的作业中过多用if-else结构，导致圈复杂度过高，在此次作业中努力去减少控制流的分支数）。因为本身作业难度不大，内聚程度的优劣没有被展现出来。

基于SOLID设计原则检查项目设计

单一职责设计原则（SRP）

此次作业的设计基本上符合单一职责原则，电梯、调度器、输入线程的工作都是分开的。
开闭原则（OCP）

因为所有类在这次作业都只被实例化一次，故未使用抽象工厂或接口来进行对象创建，此次设计在这方面仅仅是满足了一次完成作业的要求。

第二次电梯作业

作业简介

此次作业依旧是单部电梯的多线程作业，而该电梯具有捎带功能。评测时有时间要求，且含性能分。

设计策略（从多线程的协同和同步控制方面）

线程模型：观察者模式

观察者模式

在此次作业中，笔者使用的是观察者模型。对于输入线程，调度器是观察者，输入线程是消息发布者；对于调度器线程，电梯是观察者，调度器是消息发布者。当有无新的请求时，调度器和电梯线程处于阻塞状态，避免了暴力轮询而导致CPU运行时间过长；当有新的请求到来时，消息发布者会update消息，通知观察者消息有更新。