昌航面向对象步伐计划 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，那么它会优先选择它上面的楼层，但如果电梯层数