第一次Blog作业-电梯迭代作业总结

一.前言

  三次作业总结:

1.反思:三次迭代作业的题目数量适中,只是每次的电梯迭代的难度较大,时间也大部分花在在电梯题目上.虽然题目集是迭代作业,难度是逐渐提高,但是第一次的电梯作业对于"我"这个java新手小白来说难度巨大,好在有类设计的样例难度减轻不少,但电梯的运行逻辑可是让我"丈二和尚摸不着头脑",数十次的调试也难免以失败告终,好在后面两次迭代有了第一次题目的经验让我的压力减轻不少,只需要将题目的中心放在类的更改和逻辑的更新.

2.知识点:

  面向对象程序设计基础原则:单一职责,一个类一个功能,便于理解和维护.

  封装:将电梯的属性和行为封装在类中，通过方法对外提供接口，隐藏内部实现细节。

       数据结构:队列用于管理电梯内部乘客的请求队列和电梯外部乘客的请求队列。

          ArrayList列表存储电梯上下方向的请求

    算法设计:实现电梯的调度逻辑，优先处理同方向的请求，处理完同方向请求后再处理反方向请求。

二.设计与分析

   1.第一次电梯题目设计与分析

  题目要求:

设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的        请求队列，其中，电梯外部请求队列需要区分上行和下行。

  源码分析:

    (1)类的设计:

1. 1. 1. Main 类：程序的入口，负责处理用户输入，解析请求，并初始化电梯对象,使用优先队列来管理请求，能够高效地处理请求。
      2. Elevator 类 ：模拟电梯的运行逻辑，处理内部请求和外部请求。
      3. ExternalRequest 类：封装外部请求的楼层和方向,封装了外部相关信息,便于管理和比较。
      4. Direction 枚举类：定义电梯的运行方向,使用枚举类表示方向,便于管理和维护。

    (2)SourceMoniter输出结果分析:

      

• • • 平均复杂度:

第一点就是代码的平均复杂度太低了,仅仅只有1.0,这也是我第一次电梯题目没有过的原因,低于了良好代码复杂度的要求.究其原因,我认为是第一次题目思考的问题并不全面将题目过度简单化,电梯运行逻辑设计的过于简单,尤其是对于电梯的停靠,变换方向思考的不全面没有深度思考,导致代码无法正常运行出来.但平均复杂度偏低代码,便于理解和调试,也让我在后续代码改进的过程中轻松了许多.

• • • 代码注释:

图中不难看出带注释的行仅仅只有1.9%,代码注释太少可读性差,这也让我在后期的理解和修改带来了不少麻烦,经常忘记前面代码的功能,每次要在浏览一遍代码再写

• • • 代码规模:

代码整体行数是210行,对于第一次的电梯确实不够看,这也反映了我对题目理解的粗浅.其次是代码类中方法数量是13.0,说明类中方法数量较多.承担了太多不必要的功能

         (3)心得:

通过剖析第一次代码,可以深刻认识到本次电梯题目并不简单,需要进行更深层次的修改底层逻辑,优化算法.

我也总结出代码的运行逻辑如下:

首先判断是否需要打印当前楼层和方向信息。然后检查电梯内部请求队列，如果当前楼层与队列第一个请求楼层相同，则开门、关门并移除该请求；若外部请求队列也有当前楼层且方向匹配的请求，要一起处理两个请求,接着判断当前方向是否有请求，若没有则改变运行方向。最后根据运行方向移动电梯楼层(逻辑代码将在第二次电梯题目呈现).

2.第二次电梯迭代设计与分析

  1.题目要求:

对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，具体设计可参考如下类图。

  源码分析:

    (1)类的设计: 

1. 1. 1. Main 类：程序的入口，负责处理用户输入，解析请求，并初始化电梯对象,使用优先队列来管理请求，能够高效地处理请求。
      2. Elevator 类 ：模拟电梯的运行逻辑，表示电梯的属性和状态,处理内部请求和外部请求。
      3. Direction 枚举类：定义电梯的运行方向,使用枚举类表示方向,便于管理和维护。
      4. Requestqueue类:设计了ArrayList管理内部请求和外部请求,方便添加和删除。
      5. ExternalRequest类:封装外部请求的楼层和方向。
      6. ElevatorController类:控制电梯的运行,处理内部和外部请求。

    (2)类图:

 

 

 

    (3)SourceMoniter输出结果分析:

       

• • • 代码规模:代码的行数从210行增加到236,正常来说如果增加了新的类,行数应该增加很多,但第二次题目只增加了23行这是什么原因呢.因为我发现一些输入代码在运行中并没有被调用为了让我的代码更加简洁,便于修改,便把一些没有被调用的方法删去。         

• • • 复杂度:有了第一次题目集的经验,第二次电梯复杂度也提高到了从1提高到3.39,最大复杂度也从1上升到了14.这是一个相当大的进步,说明本次题目提交的代码符合预期要求,电梯的运行逻辑也更加完善,这才能让代码的复杂度提高如此之大。
    • 代码注释:代码每行注释从1.9%到2.1%,提升不大,可读性仍然很差,增加的代码注释也是新增加的类名,所以代码注释的量还是需要提高,并没有达到java代码预期量。

  (4)心得:

有了第一次电梯题目的经验,让我在第二次迭代作业中轻松了许多,第一次电梯思维逻辑的思考也在第二次作业中得到了汇报,也与我第一次题目的心得总结达成了完美的闭环.但是代码还存在注释数量太少的问题,这个问题也会在电梯题目集之后的题目逐渐改正。

3.第三次电梯迭代设计与分析

    题目要求:

对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，具体设计可参考如下类图。

      源码分析:

    (1)类的设计:

1. 1. 1. Main 类：程序的入口，负责处理用户输入，解析请求，并初始化电梯对象,使用优先队列来管理请求，能够高效地处理请求。
      2. Elevator 类 ：模拟电梯的运行逻辑，表示电梯的属性和状态,处理内部请求和外部请求。
      3. Direction 枚举类：定义电梯的运行方向,使用枚举类表示方向,便于管理和维护。
      4. Requestqueue类:设计了ArrayList管理内部请求和外部请求,方便添加和删除。
      5. ExternalRequest类:封装外部请求的楼层和方向。
      6. ElevatorController类:控制电梯的运行,处理内部和外部请求。

    (2)类图:

 

 

    (3)SourceMoniter输出分析:

      

 

• • • • • 规模:第三次迭代对比第二次代码只多了几行,这也只是稍微修改了控制类和输入的结果.

• • • • • 复杂度:第三次迭代的代码相较于第二次迭代发生了下降,我查看代码发现我并没有按照题目要求再设计一个Passenger类,只是修改了输入和电梯控制类导致了复杂度降低. 
        • 注释:第三次迭代注释也只有仅仅的1.6%,这属实是我编程的通病,这也让代码的可读性大大降

  　　(4)心得:

第三次迭代也仅仅只是在第二次迭代的基础之上进行了简单的修改,将ExternalRequest类和ElevatorController类对于外部请求的封装管理和处理做了简单的修改,代码的逻辑基本没变,初次之外呢,输入的格式和处理也根据要求进行了简单的修改.但是相较于第二次迭代的深入思考,第三次迭代我明显是有一些放松,导致代码并不能正常的运行.仔细浏览我的代码,我发现问题还是比较多,有多处的代码重复使用,这也基于我的逻辑不够清晰.还有注释的数量还是很少,这也都怪平时的懒惰和目的性太强,并没有想过代码之后的修改维护.

三.踩坑心得:

• 踩过的坑:回忆这三次题目集的迭代,我总结了我所有踩过的坑:

1. 电梯的运行原理,我最初在老师没有给新的测试样例之前单纯的认为谁离电梯近电梯就先运行到哪里,调试几次都失败后,修改了逻辑认为,电梯方向向哪里就像那个方向一直运行直到这个方向上没有请求,在转换方向运行,直到有了新的测试样例,才明白了电梯的基础运行逻辑(这也是我在第一次题目心得里所提到的),但由于时间关系,在题目集关闭之后才写出里可以正常运行的代码.因此,有了第一次题目集的经验,第二次题目集才可以正常运行通过.但第三次题目输入的修改和类的增加又让我陷入迷茫的境地,因为原来代码的运行逻辑在第三次中并不适用,将外部请求加入内部请求之后处理让我不知道怎么修改运行逻辑,导致第三次题目并没有圆满完成.
2. 类的单一职责,在第一次题目集中,并不清楚类的单一职责的重要性,将方法都会放在一个类中,导致耦合度太高,下次修改是无从下手,只能重头开始,重新写.

• 心得:经过三次迭代的训练,我也总结了一些技巧:

1. 在清楚题目的要求后,要先在PowerDesigner上写好类图,在之后编程的过程中有参照可以节省大量的时间.
2. 代码的注释一定要写,并且标明代码的具体功能,以此在下次修改的时候可以快速清楚代码写到哪个节点.
3. 明确类的单一职责,降低耦合度.

四.改进建议:

• 做到单一职责降低代码耦合度,方便代码修改,便于调试.例如Elevator这个类,直接调用了Externalrequest类的对象的方法(getFloor和getDirection),很多处地方都依赖于ExternalRequest类才能实现.
• 增加注释的数量,在每次的题目中增加注释的数量可以提高代码的可读性,便于后续代码的理解.例如第一次Elevator这个类很多If-else语句没有注释,导致后续代码难以理解,增加的修改和维护的难度

五.总结:

　　代码迭代更考验对题目要求的理解和编程能力.同时,本次代码迭代在功能和结构上取得了一定进展，增加了输入格式校验和请求封装，提升了程序的健壮性和可读性。然而，仍存在一些问题：Elevator 类与ExternalRequst类及 Direction枚举类耦合度过高，导致修改时可能相互影响；异常处理不够完善，对错误输入的反馈不够友好且缺乏详细提示；在处理大量请求时，性能表现有待优化，部分方法效率较低。未来优化方向包括：引入接口或抽象类解耦，增强异常处理机制，优化性能，以及扩展功能，如支持多部电梯协同运行和增加用户交互界面等。