昌航面向对象程序设计 5-7次电梯题目小结

一、前言

  经过大一上学习了C语言后，我熟悉掌握了一些面向过程的编程思路与方法。而在进入Java语言的学习后，且连续三次迭代的电梯大题磨练下，我开始由面向过程的思维转向面向对象的思维。三次题目集的知识点包括属性的私有化，对电梯运行过程的封装和模块化，类的单一职责，以及边界测试等知识与要求。题目一周一次迭代，题量较为适中。而难度随学习进度逐渐升级，难度曲线合理，但作为第一次写大作业，在写第一道电梯时对读题理解等都有较高的要求，需要花费一定的时间。
  下面我将分三次大作业，用SourceMonitor的生成报表内容以及PowerDesigner的相应类图等方式来讲解，分析此次题目和我的代码。同时也包含我本人的一些解释和心得，虽然算不上什么秘辛，但或许也能供自己和大家参考。
二、设计与分析

第一次电梯作业

  第一次作业的要求是设计一个电梯类，其包含最大最小楼层、当前楼层、运行状态、方向、内部及外部（区分上下行）请求队列。电梯停在默认楼层，响应请求时先处理同方向请求，再处理反方向请求，按楼层顺序逐层检查请求并开关门；设计的Java程序要实现状态管理、请求处理和调度算法，通过键盘模拟输入，测试电梯是否按规则运行。
类设计:

  本次题目为第一次电梯的编写，所以需要构建整体的算法和框架。其中核心的实现类为电梯类即为Lift，本次作业代码编写没有完全遵循类单一职责原则，该Lift类中属性为题目要求的层数、状态、内外两个队列等，而方法则包括了队列操作和电梯运行逻辑等操作。此外，由于本次题目中未使用集成框架，我额外编写了Node类，和List类来模拟链表、队列的一些功能，从而人工实现了队列的一些基础操作。最终程序的实现是通过遍历电梯对象中的两个传入的队列，与电梯当前状态和方向相比较，不断得到下一个该去的楼层，当到达后目标后去掉同层所有请求，重复操作，直到两个队列清空为止。
代码分析:

  由代码的静态度分析来看：
（1）代码规模：代码有262行，178条语句，语句密度≈ 0.67（178÷262），代码的规模较为适中。
（2）类分析：总共四个类，每个类平均有5、6个方法，每个方法平均7条语句说明日常逻辑较为简洁。
（3）代码注释：注释行占比为%5，注释占比相对较低，在一些关键行和关键分支时的注释可能不够，代码的可读性和理解性不高。
（4）代码结构：最大块深度达到 5 层，而区间分布显示有近六成语句处于深度 2～3 的嵌套，说明有一定部分的代码逻辑较为复杂，使得代码的可读性、可维护性、可调式性都不够好。
（5）代码复杂性：而代码最复杂的方法Lift.target();其圈复杂度达到了28，过于复杂，可能造成难以理解和调试等问题。
（6）分支与方法调用：分支语句占比：25.3 %，逻辑复杂度中等偏上。方法调用数：74 次，约占总语句的 41.6 %，调用频率合理；但在target方法中调用链过长，性能与测试性方面存在问题。
第二次电梯作业

  第二次作业的要求是对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，此外还要求处理如下情况：
乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行；
乘客请求不合理，具体为输入时出现连续的相同请求，例如或者，处理方法：程序自动忽略相同的多余输入，继续执行，例如过滤为。
类设计:

  第二次的电梯题目在第一题的基础上要求实现四个类，即类图中的Lift电梯类，Request乘客请求类，Controller控制类，以及RequestQueue队列类。本次代码使用了LinkedList来存储队列信息，代替了第一次作业中的人工实现的队列类，此外将之前第一次作业中的电梯运行的相关逻辑转移重构到了控制类，将电梯类中的队列及其相关操作转移重构到了队列类，每一个用户的请求都是一个乘客请求类，这些类的改变使得类的设计基本遵循了类单一职责的原则，贴合题目以及实际的要求。之后在电梯类中按照题目要求引入了一个判断数据是否有效的boolean类型方法，从而实现在题目要求所给的异常数据处理，而其他基本算法相比第一次变化不大。
代码分析:

  由代码的静态分析来看：
(1) 代码规模：总行数325行、语句194条，规模仍属中等偏上。语句密度≈ 0.60（194÷325），与一般Java项目相当，说明一行通常只承载一条逻辑语句，可读性尚可。
(2) 类分析：共5个类，平均每类≈6.8个方法。方法平均语句数≈4.2，日常业务代码较为精简。不过Controller类内聚度偏低：单独占了10个以上方法，其中gettarget方法异常庞大，后期调试压力可能会集中在这一个类上。
(3) 代码注释：注释行占比仅2.8%，占比较低。关键分支、复杂算法（如调度策略）基本缺少中文或英文说明，使得阅读成本高。
(4) 代码结构：最大块深度 5 层；26行代码处达到最深嵌套。近37%语句处于3层以上嵌套，阅读与调试都会受影响。
(5) 代码复杂性：平均圈复杂度 2.85，整体尚可。最复杂方法Controller.gettarget()：复杂度为33、语句数34、块深度为5、调用96次，过于复杂，需要继续拆分。
(6) 分支与方法调用：分支语句占比22.2%，逻辑复杂度中等；主要集中在changedirection()、checkrequest()与gettarget()。方法调用169次，占语句总数≈87%，调用次数过多来驱动程序导致影响后续测试与调试，同时也让代码的性能降低。
第三次电梯作业

  第三次作业的要求是对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，而电梯运行规则与前阶段相同，但有如下变动情况：
乘客请求输入变动情况：外部请求由之前的修改为
对于外部请求，当电梯处理该请求之后（该请求出队），要将中的请求目的楼层加入到请求内部队列(加到队尾）。
类设计:

  第三次电梯题目将之前的乘客请求类改为了Passenger乘客类，该类属性相比之前请求类的层数、方向改为了当前楼层和目标楼层。由于乘客类的引入和其属性的变化，导致之前直接通过比较乘客请求类里的方向属性和电梯层数、当前方向的方法来决定电梯运行逻辑失效，于是我在乘客类添加了一个Direction()方法：即通过判断乘客的当前楼层和目标楼层来得出方向，从而可以在稍加修改其他类的基础上继续套用之前的算法。于是本次类的设计除了乘客类的加入和部分方法内容修改外，基本的设计与第二次相似。
代码分析:

  由代码的静态分析来看：
(1) 代码规模：总行数340行、语句203条，规模属中等偏上。语句密度≈ 0.60（203÷340），说明一行通常只承载一条逻辑语句，可读性尚可。
(2) 类分析：共5个类，平均每类≈7个方法。方法平均语句数≈4.31，业务逻辑总体简洁。不过Controller类依旧承担过多职责。
(3) 代码注释：注释行占比仅 2.1 %，关键分支、调度算法与边界处理几乎无说明，新成员理解难度高。
(4) 代码结构：最大块深度 5 层（出现在第 26 行）。约 37 % 语句位于 3 层及以上嵌套，可读性、可调试性和可维护性受到明显影响。
(5) 代码复杂性：平均圈复杂度 2.89，整体尚可。最复杂方法 Controller.getTarget()：复杂度 33、语句 34、块深度 5、被调用 102 次，该方法过于复杂。
(6) 分支与方法调用：分支语句占比 22.7 %，逻辑复杂度中等；主要集中在changedirection()、checkrequest()、getTarget() 等。方法调用175次，占语句总数≈86%，既影响性能，也增加测试难度。
三、采坑心得：

第一次电梯作业


  第一次作业由于是最开始接触全新的电梯大题，因此也是花费最长时间的一次大作业。当总结起来花费时间的原因时，我发现很大一部分在于读题审题的问题。面对这样一个相当长度的题目以及老师发的各种讲解，我一开始是没有耐心去细致分析的题目的，就连一开始题目提到的end不区分大小写都没有看到。

反而我当时抱着侥幸心理，想着先写点代码也许就能过测试点。而我最初写的代码完全忽视了方向优先策略和LOOK算法。

直到老师开放讨论区，并发布新的测试样例，此时我才发现自己的代码完全不符合规律，只是表面上巧合与题目的样例相同，此时我才静下心来分析电梯运行的过程，查阅老师发的各种资料，最终不断在样例的检验下调试出了获取下一个目标楼层（例如：电梯此时方向为UP，那么它会优先选择它上面的楼层，但如果电梯层数