面向对象第二单元总结

阳光穿透心脏的1/2处 2021-11-26 12:06 308阅读 0赞

# 面向对象第二单元 #

## 前言 ##

第二单元作业中，逐次递进开发一个多线程电梯模拟系统。单部傻瓜电梯->单部可捎带电梯->多部分楼层电梯。经过第一单元的开发，本单元里更注重可扩展性，较好地避免了重构。  
本次作业中，依然是将前两次作业统一叙述，第三次作业单独叙述，并在最后综述此单元作业中对**面向对象模式**的应用。

## 设计模式(多线程协同策略) ##

在第三次作业中，很容易就想到生产者、消费者模式。维护一个电梯与调度器之间的请求队列。电梯（消费者）不断地从队列中take请求，如果队列是空的，则进入阻塞状态。调度器每往队列中放入请求，则唤醒电梯。此时，加锁对象是共享队列。  
在实现上，我用了阻塞队列，这是一种很好的实现方式，避免了加锁运用不熟练而产生的bug。

![1616705-20190422142305972-1582184834.png][]

实际上，输入端也应该由一个线程运行，因此将输入端与调度器分离，同样通过一个共享队列交互。调度器内没有剩余请求，而队列内也没有请求，则进入wait态，等待有新的输入时，输入线程会唤醒调度器线程。

对于第三次作业，则在调度器与每个电梯之间都维护一个Tray，调度器分给x号电梯请求，则会将x号电梯唤醒（此时电梯可能仍是就绪态，不要紧）。而电梯每次运行时则会将Tray内的请求拖拽到自己的队列中，减小耦合。

![1616705-20190422142508636-2071552019.png][]

另一个问题，则是考虑如何结束程序。我使用了类似**两阶段终止**的方法(如上图)。在我们的作业中，唯一的终止信号是输入端的C^d ,代表输入流终止。 这个信号发出后，对输入线程的flag静态变量置True，并唤醒调度器。调度器运行时，检测在所有请求都分配出去、输入线程flag为true时，调度器flag 置为True，并唤醒电梯。 电梯完成所有调度任务，并且监测到调度器关闭，自己也停止运行。至此，三个线程都安全终止，jvm自然退出。

![1616705-20190422142322969-45557146.png][]

在第三次作业中，为了很好地处理“乘客可能需要换乘”的需求，设计了副调度器。分析一下这个需求，其实是完成现实生活中“我坐上第一部电梯，到达中间楼层，自己再自觉排队继续后半程”的情况。因此，主调度器的职责变成了“找到电梯并拆解请求，将后半程请求扔给副调度器的Tray”。而电梯则是在将乘客送到目的地后，把乘客ID 放进副调度器的Tray中，唤醒副调度器。副调度器遍历“出电梯”的乘客，并在主调度器扔来的“副请求”中寻找是否存在相应的副请求，存在，则为其寻找电梯进行调度。

![1616705-20190422142328928-796883000.png][]

在这种策略下，终止模式则变成了：输入线程停止->主调度器停止->副调度器停止（均分配完且主调度器停止）->三部电梯停止。

另外，主调度器和副调度器都使用了单例模式，防止产生不同的调度器实例。

## 第一、二次作业：单部电梯 ##

### 第一次 ###

#### 代码量 ####

<table> 
 <thead> 
  <tr> 
   <th>source file</th> 
   <th>total lines</th> 
   <th>souce code lines</th> 
   <th>source code lines%</th> 
   <th>coment line counts</th> 
   <th>comment line counts%</th> 
   <th>black lines</th> 
   <th>blank lines count%</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Channel.java</td> 
   <td>12</td> 
   <td>6</td> 
   <td>0.5</td> 
   <td>0</td> 
   <td>0</td> 
   <td>6</td> 
   <td>0.5</td> 
  </tr> 
  <tr> 
   <td>Evelator.java</td> 
   <td>15</td> 
   <td>7</td> 
   <td>0.466666667</td> 
   <td>0</td> 
   <td>0</td> 
   <td>8</td> 
   <td>0.533333333</td> 
  </tr> 
  <tr> 
   <td>InputStream.java</td> 
   <td>33</td> 
   <td>26</td> 
   <td>0.787878788</td> 
   <td>0</td> 
   <td>0</td> 
   <td>7</td> 
   <td>0.212121212</td> 
  </tr> 
  <tr> 
   <td>MainClass.java</td> 
   <td>39</td> 
   <td>30</td> 
   <td>0.769230769</td> 
   <td>0</td> 
   <td>0</td> 
   <td>9</td> 
   <td>0.230769231</td> 
  </tr> 
  <tr> 
   <td>MainClassTest.java</td> 
   <td>50</td> 
   <td>34</td> 
   <td>0.68</td> 
   <td>0</td> 
   <td>0</td> 
   <td>16</td> 
   <td>0.32</td> 
  </tr> 
  <tr> 
   <td>NudeEvelator.java</td> 
   <td>413</td> 
   <td>331</td> 
   <td>0.801452785</td> 
   <td>18</td> 
   <td>0.043583535</td> 
   <td>64</td> 
   <td>0.15496368</td> 
  </tr> 
  <tr> 
   <td>Scheduler.java</td> 
   <td>69</td> 
   <td>54</td> 
   <td>0.782608696</td> 
   <td>1</td> 
   <td>0.014492754</td> 
   <td>14</td> 
   <td>0.202898551</td> 
  </tr> 
  <tr> 
   <td>WaitingQueueChannel.java</td> 
   <td>28</td> 
   <td>22</td> 
   <td>0.785714286</td> 
   <td>0</td> 
   <td>0</td> 
   <td>6</td> 
   <td>0.214285714</td> 
  </tr> 
 </tbody> 
</table>

![1616705-20190422142335771-893817657.png][]

#### 方法分析 ####

<table> 
 <thead> 
  <tr> 
   <th>method</th> 
   <th>ev</th> 
   <th>iv</th> 
   <th>v</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>dormouse.InputStream.run()</td> 
   <td>3</td> 
   <td>5</td> 
   <td>5</td> 
  </tr> 
  <tr> 
   <td>dormouse.MainClass.getInput()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.MainClass.getRequestQueue()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.MainClass.main(String[])</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.MainClass.setInput(InputStream)</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.MainClass.setRequestQueue(WaitingQueueChannel)</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.MainClassTest.innerThread.run()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.MainClassTest.main()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.addRequest(PersonRequest)</td> 
   <td>1</td> 
   <td>6</td> 
   <td>6</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.chooseNextStateOfRun()</td> 
   <td>3</td> 
   <td>7</td> 
   <td>7</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.chooseNextStateOfStay()</td> 
   <td>1</td> 
   <td>4</td> 
   <td>4</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.closeTheDoor()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.doRun()</td> 
   <td>1</td> 
   <td>6</td> 
   <td>6</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.doSomething()</td> 
   <td>1</td> 
   <td>4</td> 
   <td>4</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.fetchNewPassenger()</td> 
   <td>1</td> 
   <td>3</td> 
   <td>3</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.getCurFloor()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.getDirecTion()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.getDownLight()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.getEndFlag()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.getEveLight()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.getEveState()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.getRelativeDir(int,int)</td> 
   <td>2</td> 
   <td>1</td> 
   <td>2</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.getTargetFloor()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.getTransportQueue()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.getUpLight()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.getWaitingQueue()</td> 
   <td>1</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.goDown()</td> 
   <td>1</td> 
   <td>2</td> 
   <td>2</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.goUp()</td> 
   <td>1</td> 
   <td>2</td> 
   <td>2</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.joinTrans(PersonRequest)</td> 
   <td>1</td> 
   <td>2</td> 
   <td>2</td> 
  </tr> 
  <tr> 
   <td>Total</td> 
   <td>68</td> 
   <td>109</td> 
   <td>115</td> 
  </tr> 
  <tr> 
   <td>Average</td> 
   <td>1.152542373</td> 
   <td>1.847457627</td> 
   <td>1.949152542</td> 
  </tr> 
 </tbody> 
</table>

#### 类分析 ####

<table> 
 <thead> 
  <tr> 
   <th>class</th> 
   <th>Ocavg</th> 
   <th>WMC</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>dormouse.InputStream</td> 
   <td>3</td> 
   <td>3</td> 
  </tr> 
  <tr> 
   <td>dormouse.MainClass</td> 
   <td>1</td> 
   <td>5</td> 
  </tr> 
  <tr> 
   <td>dormouse.MainClassTest</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.MainClassTest.innerThread</td> 
   <td>1</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator</td> 
   <td>1.75</td> 
   <td><strong>70</strong></td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.CurState</td> 
   <td>0</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.MoveDir</td> 
   <td>0</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>dormouse.Scheduler</td> 
   <td>1.75</td> 
   <td>14</td> 
  </tr> 
  <tr> 
   <td>dormouse.WaitingQueueChannel</td> 
   <td>1.333333333</td> 
   <td>4</td> 
  </tr> 
  <tr> 
   <td>Total</td> 
   <td>0</td> 
   <td>98</td> 
  </tr> 
  <tr> 
   <td>Average</td> 
   <td>1.661016949</td> 
   <td>10.88888889</td> 
  </tr> 
 </tbody> 
</table>

在第一次作业中，只有NudeElevator 的WMC**爆红**。究其原因，是因为我在第一、二次作业中均用了捎带算法运行电梯，电梯自身逻辑完整，只需根据输入的请求就能自己拉取并执行。无需更改。因此，无论是代码行数还是复杂度，均是电梯类最多(高)。

#### 类图评价： ####

为了更好地支持扩展，我将电梯和共享队列封装成接口，共享队列的BlockingQueue在WaitingQueueChannel中实现，并且使用了泛型，以满足不同类型的共享队列

public class WaitingQueueChannel<P> implements Channel<P> {
        private final BlockingQueue<P> queue;  
        ......
        
    }
    
    //channel.java  interface
    public interface Channel<P> {
    
        LinkedList<P> take();
    
        void put(P product) throws InterruptedException;
    }

### 第二次 ###

#### 代码行数： ####

代码复杂度分析这里不放图了（节约空间），与第一次相比，这次所有复杂度指标都在合理范围内。  
上图中，代码行数只放了与第一次相比改变的部分。可以看到，由于第一次作业中良好的可扩展性设计，第二次作业中Elevator类几乎没有增加代码。Scheduler中稍有增加（为第三次作业中的扩展做准备）  
新增了类：**floor**。由于第二次作业中支持了地下楼层：-1层，-1层的上一层是1层，因此，用Integer表示楼层并不能很好地支持设计，因此，将楼层逻辑封装成一个类，便于电梯和调度器使用。

public class Floor {
        private int floor;
        
        @Override
        public String toString() {
            return String.format("%d", getFloor());
        }
    
        public void increase() {
           ...
        }
    
        public void decrease() {
           ...
        }

#### 第二次类图： ####

![1616705-20190422142354508-1714291483.png][]

#### 类图评价： ####

可以看到，第二次作业中新增的floor ，仅与elevator有交互。实际上，floor也是专门提供给电梯表征电梯状态的。电梯类中，由于用了IDEA自动重构，很多private变量多出了不必要的访存方法（他们只在elevator内部使用到），这一问题在第三次作业（和今后的作业）中加以解决。

## 第三次作业：多部分楼层电梯 ##

#### 代码规模： ####

第三次作业中，将电梯内部另一个状态Light封装成新的类，其功能和作用在下一部分提及。  
新增了ViceScheduler(副调度器)类，其继承于主调度器，也产生一个单例模式的实例。电梯运行逻辑与第二次作业相同，新增了一些属性（承载人数...）。在我的设计模式下，满载条件由调度器控制，保持了电梯的纯净（在电梯看来，依然是只要有请求来，就去执行，一定程度上减少了我修改的麻烦）。

#### 复杂度： ####

<table> 
 <thead> 
  <tr> 
   <th>class</th> 
   <th>Ocavg</th> 
   <th>WMC</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>dormouse.Floor</td> 
   <td>1.25</td> 
   <td>10</td> 
  </tr> 
  <tr> 
   <td>dormouse.InputStream</td> 
   <td>3</td> 
   <td>3</td> 
  </tr> 
  <tr> 
   <td>dormouse.Light</td> 
   <td>2</td> 
   <td>10</td> 
  </tr> 
  <tr> 
   <td>dormouse.MainClass</td> 
   <td>1</td> 
   <td>5</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator</td> 
   <td>1.9375</td> 
   <td><strong>62</strong></td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.CurState</td> 
   <td>0</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>dormouse.NudeEvelator.MoveDir</td> 
   <td>0</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>dormouse.Scheduler</td> 
   <td>2.705882353</td> 
   <td><strong>46</strong></td> 
  </tr> 
  <tr> 
   <td>dormouse.ViceScheduler</td> 
   <td><strong>3.8</strong></td> 
   <td>19</td> 
  </tr> 
  <tr> 
   <td>dormouse.WaitingQueueChannel</td> 
   <td>1.333333333</td> 
   <td>4</td> 
  </tr> 
  <tr> 
   <td>Total</td> 
   <td>0</td> 
   <td>161</td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <thead> 
  <tr> 
   <th>method</th> 
   <th>ev</th> 
   <th>iv</th> 
   <th>v</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>dormouse.ViceScheduler.run()</td> 
   <td>3</td> 
   <td><strong>15</strong></td> 
   <td><strong>16</strong></td> 
  </tr> 
  <tr> 
   <td>dormouse.Scheduler.run()</td> 
   <td>3</td> 
   <td><strong>10</strong></td> 
   <td><strong>11</strong></td> 
  </tr> 
  <tr> 
   <td>dormouse.Scheduler.passengerDontLike(int,PersonRequest)</td> 
   <td>1</td> 
   <td>9</td> 
   <td><strong>14</strong></td> 
  </tr> 
 </tbody> 
</table>

在第三次作业中，调度器的复杂度超出了标准。究其原因，是选择电梯的逻辑稍微复杂。以及选好电梯后，还要进行请求的拆解并加给副调度器。这部分由于可能的情况太多，导致我编码时产生了很多的分支，因此显得代码臃肿了些。

#### 类图： ####

![1616705-20190422142411406-915178905.png][]

#### 类图评价： ####

第三次作业中，虽然新增了两个类，但他们控制范围与交互的对象是很清晰的： Light服务于电梯， ViceScheduler一方面与Scheduler交互（通过继承实现），另一方面与电梯交互（其所用的共享队列也通过继承而来）。实现难度大大降低。

## 设计Tricks （UML协作图） ##

--------------------

### 电梯自动机： ###

电梯的逻辑方面，我为电梯设计了一个有限自动机：  
电梯只有三种状态：IDLE / RUN / STAY ,在三种状态下根据输入（请求信息）运行。

private void doRun() throws InterruptedException {
            //other code
            .......
          
            if (getEveState() == CurState.idle
                    && !getWaitingQueue().isEmpty()) {
                doSomething();
            } else if (getEveState() == CurState.run) {
                chooseNextStateOfRun();
            } else if (getEveState() == CurState.stay) {
                chooseNextStateOfStay();
            }
    
        }

这里提一下Light的作用：相当于我们乘坐电梯时的按钮灯：灯亮，代表此层楼有人上楼/下楼，需要停下来接人。由于人可能上楼或下楼，因此每部电梯灯有两套：上楼灯和下楼灯。具体访问那套灯由电梯此时状态（上下楼方向决定），如果此层楼灯亮或者有人离开电梯，电梯才会在此层楼从RUN变为STAY状态（公测的BUG就是这里发生的）。

### 线程协作： ###

![1616705-20190422142445410-1203497794.png][]

## Bug发现： ##

--------------------

第一次作业，在中测阶段我用了10次机会（血压拉满，极限提交）才全部通过。原因在于：1、第一次接触多线程，对于程序终止掌握的不是很好。尝试几次后才写对。 2、直接尝试捎带策略，对于电梯的有限自动机也设计了很久，并在细微之处多次修改。  
这样做也有一定的好处:后面两次设计中不用太多修改电梯部分，节约了很多时间。并且在第一次公测中没有发现错误。

第二次作业，中测阶段一次提交成功。但也发生了一大**惨案**：公测阶段最后三个点全错。排查之后发现：是因为在设计电梯逻辑时，最高楼层定义错误-----MAX\_FLOOR =15 (实际应为16)。 需要解释一点，这一变量并不会直接导致电梯逻辑出错，而是影响到电梯的Light（对于负楼层电梯，其Light 为 MAX \_FLOOR- floor，因此-1层和16层电梯灯重合）。产生错误的原因是：16层的电梯请求会关闭-1层的电梯灯，导致电梯如果存留“负一层需要停下”的信息，而负一层灯还没亮，最后会在负一层来回开关门而不放进来乘客。

事后诸葛亮地看，第二次作业的自我测试确实不到位。因此，在第三次作业中，赶紧把**电梯灯**的逻辑抽离出来封装成一个类，方便排错。并且，测试阶段，随机生成大量请求，抛给电梯执行，尽最大可能地避免错误。第三次作业中没有出现公测错误。

只不过，后两次作业里，性能分基本没拿到，这一点令我很吃惊。我用的是 **SCAN**算法，并参考日常生活中实际电梯的运行模式，但收获的效果并不好(几乎都在平均值下还行）。调度策略部分留待日后再自己分析吧。

--------------------

## 后记(能否加入更多的设计模式 && SOLID ) ##

本系列作业中尽可能地降低各个线程 所在类之间的耦合（事实上这么做也更方便编程，减少了线程间共享对象），对于泛型和接口的使用（虽然接口最后没用上），简化了不同类型共享队列重复编码。每次增量开发也更加顺手，总的来看，相比第一单元有了很大进步。

本系列作业中重视设计模式和可扩展性，因此没有重构的情况发生，都是“增量式开发”。用了单例模式、生产者消费者、两阶段终止 模式，进一步加强了接口和集成的训练。  
如果要更进一步地思考，在电梯调度策略上，还有进步的空间，可以把**策略模式**加入调度器里，实现调度策略的封装使用。和伙伴交流了一下，运用图算法和相应的数据结构进行存储，也许会有不错的效果？  
***压力马斯内！***  
2019.4.22  
16231213  
By:DorMouse

转载于:https://www.cnblogs.com/DorMouse-Rui/p/10749908.html

[1616705-20190422142305972-1582184834.png]: /images/20211126/cb96f32a31dd40308b55fd0b60dd9a62.png
[1616705-20190422142508636-2071552019.png]: /images/20211126/010b2ddc03ad439f8a2697d8b730b681.png
[1616705-20190422142322969-45557146.png]: /images/20211126/3588821b1506492187aaa4dfff7d7617.png
[1616705-20190422142328928-796883000.png]: /images/20211126/3407d67168344fafa239dcc3b0517370.png
[1616705-20190422142335771-893817657.png]: /images/20211126/d21d60e9ed174bf09a4e52319e8737b9.png
[1616705-20190422142354508-1714291483.png]: /images/20211126/0af59c389928428cac6427118f457770.png
[1616705-20190422142411406-915178905.png]: /images/20211126/2af66f9d8d124fbeafaa3f034ced9922.png
[1616705-20190422142445410-1203497794.png]: /images/20211126/51d9884b8c7d43feb074a17d093c703f.png