关于对电梯系统进行迭代的阶段性总结
**前言**
在过去的三个星期，我们就单部电梯的额调度进行了代码编写，以及迭代，可以说这是一段十分具有挑战性的新体验。
在对电梯调试以及迭代的三次实验中，我们需要完成设计电梯以初始楼层为一层运行，接受内部以及外部命令，需要对外部以及内部指令进行分步处理，当我们在运行电梯时优先处理同方向的请求，继而处理非同方向的，在对电梯的调试过程中，我觉得电梯调试题量略大，难度具有一定的挑战性可以让我们更好地按照需求设计java代码，总的来说此次电梯调试涉及多方面代码调试知识，讲求类与类之间的协作，是一个综合性非常强的设计对象。
**设计分析**
接下来我会说明这三次实验的代码编写情况以及代码的分析。
第一次电梯作业
为了更好的了解电梯运行的逻辑，首先我们可以了解一下第一次电梯所给的类图。
以上便是我所写代码的类图，我们来进行分析，依照上述类图所言，我所写的类图中包含三个类，一个电梯类一个用于处理外部存储的类以及一个调用所有类的主类，在这些类中我们可以看出，单部电梯的电梯类中几乎包含了所有电梯调用的方法，因此可以说这一个类十分复杂，是一个相当集合的类
接下来是对于我所写的代码复杂度的分析
根据上述对代码的静态分析如下
行数：156 行，文件规模适中，不算特别长，但也不是非常短小的代码文件。
语句数：100 条语句，反映了代码实现功能的具体操作数量。
分支语句百分比：13.0%，意味着大约有 13% 的语句是分支语句（如 if、switch 等），说明代码中有一定的逻辑判断。
方法调用语句数：37，表示代码中方法调用的频繁程度，一定程度上反映了代码的模块化程度。
注释行百分比：7.1%，注释较少，可能会影响代码的可读性和维护性。
类和接口数量：1，即只有一个类 Elevator，代码结构相对简单。
每个类的方法数：10.00，说明该类封装了多个方法来实现电梯相关的功能。
每个方法的平均语句数：7.60，平均每个方法包含 7.6 条语句，方法规模相对较为均衡。
最复杂方法分析：
Elevator.move ()：
复杂度：12，复杂度较高，是所有方法中复杂度最高的。
语句数：23，包含 23 条语句，逻辑较为复杂。
最大深度：4，块深度达到 4，说明方法内存在多层嵌套的逻辑结构（如 if 语句嵌套等）。
调用次数：11，频繁调用其他方法，进一步增加了方法的复杂性。
Elevator.addinRequest () 和 Elevator.addoutRequest ()：
复杂度：5，复杂度中等。
语句数：4，语句较少，但复杂度相对较高，可能是由于有一定的逻辑判断（如输入合法性检查）。
最大深度：3，存在一定的嵌套逻辑。
调用次数：1，调用了一次其他方法，可能是进行输入合法性检查等操作。
Elevator.Elevator ()（构造函数）：
复杂度：1，复杂度最低，语句简单，主要用于初始化成员变量。
语句数：9，包含 9 条语句进行初始化操作。
最大深度：2，嵌套程度较低。
调用次数：0，没有调用其他方法。
Elevator.run ()：
复杂度：3，复杂度较低。
语句数：2，语句较少，主要是一个循环来控制电梯的运行，逻辑相对简单。
最大深度：3，存在一定的嵌套逻辑。
调用次数：1，调用了 move () 方法来实现电梯的移动。
块深度分析：
深度为 0：4 条语句，说明有 4 条语句是在最外层，没有嵌套逻辑。
深度为 1：20 条语句，有 20 条语句处于一层嵌套的逻辑中。
深度为 2：29 条语句，较多语句处于两层嵌套的逻辑中。
深度为 3：26 条语句，说明代码中存在较多的三层嵌套逻辑，这可能会使代码的理解和维护变得困难。
深度为 4：5 条语句，虽然数量较少，但也增加了代码的复杂性。
深度为 5、6、7：分别有 6、2、8 条语句，这些深度较高的嵌套逻辑进一步增加了代码的复杂性。
根据以上对图表的分析，我们可以判断此段代码各个类的嵌套关系并不深入，依赖关系较多，但是代码注释较少，可能对代码的解读有些困难
这里提出改进建议：代码中存在较多的多层嵌套逻辑，可通过提取逻辑到子方法、使用 return 提前返回等方式减少块深度。例如，在 handleCurrentFloorRequests() 方法中，使用 return 提前返回，避免后续逻辑的嵌套。使用枚举代替字符串表示方向
使用字符串 "UP" 和 "DOWN" 表示电梯方向不够安全，容易出错。可以使用枚举类型来表示方向。
可以看出代码仍有不少问题的，为了更好的实现单部电梯的捎带流程，我在之后的单部电梯调试中将进一步修改代码，在初次编写电梯代码时还是比较有挑战性的，在尝试编写代码时也存在不少问题。
第二次电梯作业
此次作业时对第一次作业代码的进一步迭代调试，在电梯调试的基础上，对电梯的类进行进一步的划分，，将其分成四个类，现在让我们来了解一下这个作业的类图
可以十分清晰地看到，对于这部电梯我们需要在上一次电梯的基础上将方向与状态分成两个枚举类，而我们对电梯的控制将集中于控制类中，接下来是我所写代码的静态分析
可以从上述图片进行分析
类的数量：文件中存在 6 个类和接口。方法平均数量：每个类平均有 6.83 个方法，这显示出类的功能可能较为丰富，但也可能暗示类的职责不够单一方法平均语句数：每个方法平均有 2.85 条语句，这说明大部分方法比较短小精悍，不过也有可能存在很多简单的存取方法。
最高复杂度方法：Controller.move() 方法复杂度达到 17，位于第 153 行。此方法复杂度较高，可能是因为其中包含较多的条件判断、循环或者嵌套逻辑，需要重点审查和优化。平均复杂度：平均复杂度为 1.88，整体复杂度不算高，不过 Controller.move() 方法的高复杂度拉高了整体复杂度的数值。
最大代码块深度：最大代码块深度为 5，位于第 282 行。代码块深度过深会使代码的可读性和可维护性变差，需要检查是否存在过多的嵌套结构。平均代码块深度：平均代码块深度为 1.96，处于一个相对合理的范围。
分支语句占比：分支语句占比为 11.0%，比例不算高，这表明代码里的条件判断逻辑相对较少。方法调用语句：有 82 条方法调用语句，说明代码的模块化程度尚可，不同方法之间存在一定的调用关系
代码块深度为 0 的语句有 7 条，这部分通常是全局变量声明或者类定义等。
代码块深度为 1 和 2 的语句数量较多，分别为 54 条和 76 条，这是代码的主要组成部分。
代码块深度达到 5 及以上的语句数量较少，仅 3 条，说明深度过深的代码块占比不大，但仍需关注。
这次修改比较容易，但是代码仍有需要改进之处，可以在代码的可读性和可维护性再下点功夫，代码的核心逻辑未进行变更，修改了一些函数调用使得代码复杂度降低一定程度，但是依据类图我所写的代码，类之间的耦合性可能比预想的要高，反而在依赖性方面倒是没有太多体现。
第三次电梯作业
第三次电梯作业比起前两次电梯作业输入有较大不同，取消了外部方向的处理反而添加了乘客对目标楼层和原始楼层的输入，需要创建乘客类读取输入，下面请看流程图
可以看出，通过上述类图，我们要将乘客输入的电梯指令，在乘客类中处理自动装箱，然后代入控制类中继续使用，接下来是我所写代码的静态分析
可以由上述代码分析图看出
方法数量：每个类平均有 14.00 个方法，这个数值较高，可能意味着类的职责相对集中，或者存在一些功能聚合度较高的类。
方法平均语句数：平均每个方法有 5.25 条语句，比 elevtor2.java.txt 的 2.85 条要多，说明这里的方法可能相对更复杂一些，或者逻辑更集中。
最高复杂度方法：最复杂的方法是 Main.main() ，位于第 241 行，复杂度为 8 。与 elevtor2.java.txt 中最复杂的 Controller.move() 方法（复杂度 17 ）相比，复杂度较低。不过，Main.main() 作为程序的入口方法，复杂度为 8 也需要关注，可能需要进一步优化其逻辑，使其更加清晰和易于维护。
平均复杂度：平均复杂度为 8.00 ，这可能是由于 Main.main() 方法的复杂度对整体平均产生了较大影响，因为只有这一个方法复杂度较高，其他方法可能相对简单。
最大代码块深度：最大代码块深度为 7 ，位于第 259 行，比 elevtor2.java.txt 的最大代码块深度 5 更深。深度过深的代码块会使代码逻辑难以理解和调试，需要检查是否可以通过重构减少嵌套层次。
平均代码块深度：平均代码块深度为 1.54 ，比 elevtor2.java.txt 的 1.96 略低，说明整体代码块的嵌套情况相对较好，但仍需关注深度较大的代码块。
分支语句占比：分支语句占比为 19.2% ，高于 elevtor2.java.txt 的 11.0% ，这表明该文件中条件判断逻辑相对更多，可能导致代码的执行路径更加复杂。
方法调用语句：有 79 条方法调用语句，与 elevtor2.java.txt 的 82 条接近，说明代码在方法之间的调用关系方面与之前的文件类似，模块化程度尚可。
可以看出由于这次作业的输入输出有了一些变化，在修改代码的过程中也遇到了十分苦恼的挑战，在编写控制类的逻辑中我陷入了一些困境，导致最后的代码并不彻底完善，但是中间经过调整，稍微解决了这样的麻烦
以上就是我三次作业所写的作业要求，以及代码的分析结果。
踩坑心得
通过此次的作业完成的过程经历，我曾在编写电梯运行逻辑代码核心中，出现过问题，在追求同方向优先的前提下，我只盯着同方向而忽略了其他条件在编写这一段的代码的时候，我在控制类中进行了对存储外部及其内部指令的地方采用了循环处理，但是由于我没有考虑到在底层停靠以及代码的输入顺序的问题，导致了寻找下一楼层的时候，总是会跳过一些楼层，从而无法打出这个楼层造成错误，到最后才打破了这个逻辑，还有，在是否确认关门开门时我犯了一个错误，在确认是否开门时应当时当cuurentFloor与目标楼层相同时开门，但我使用了contain方法对其进行判定，但是如果输入的楼层相同按时时间不同时，先输入的指令会覆盖后面的指令将其移除列表，这时候问题出现了，就是在这是同一个楼层会在这里同时开门关门两次，因此我试了很多次却没法排除这样的问题，好在在最后时，我修复了这个逻辑从而使得输出回到了正确的轨道上。所以以上踩坑的经历告诉我在写对象时考虑一定要更加全面才行，在逻辑上的谬误很可能就会让自己在原地打转，修不出bug，同样因为注释的缺失导致我在回顾自己所写代码的情况下，找不到更加具体的逻辑错误点，所以在之后写代码时一定要加上必要的注释。
改进建议
在编写代码以及分析代码的结果上来看，我对代码的注释部分还是过少了，在作业我虽标注了类名但是这点注释可能对整体的代码可读性并没有太大的帮助，所以我可以在后续的代码上编写注释，来辅助他人对我代码的解读，同时在我进行修改时提供一定的帮助
在编写代码的分析中，代码的耦合度可能有点过高，使得代码的维护变得十分困难，所以在之后的代码改进中我们可以适当降低代码的关系程度，使得代码更加清晰，在修改代码时也能不这么费力。
在分析中，我看到分析软件评判我的代码中某些类调用方法太多，那么我可以在后续的代码编写过程中明确单一职责，可以让类的功能更加具有特异性，以让代码更清晰。
在分析中，同样分析器认为我的代码中的某些类，太过于复杂，这严重影响到了代码的可读性及其维护成本，所以我们之后可以降低编写类的复杂度。
在编写代码中，我可以在之后使用更好的正则表达式来进行对输入的读取，这样可以简化我对于main函数的构造以及使得代码更简单。
总结
通过三次大作业的编写我学到了许多，我在对类的调用和类的协作的使用更加熟练，同样我也学会了使用一些特别的方式去处理数据，我第一次在编程中使用枚举类型进行编码，我在编写中同时也遇到了很多挑战，我在对使用Java中的链表类型可能并不熟练，其中一些相关链表的java库函数，我调用起来比较困难，其次对于一些自动拆包我仍有一些概念的缺失，所以我需要巩固自己的相关基础知识，我认为我需要对正则表达式进一步学习，在大作业的进行时我学会了很多编写代码的知识，以及对面对对象有了更深刻的认识，期待老师能在之后的作业中能够添加更多详细的要求来供我们进行参考，希望以后的实验类型可以与大作业的实验类型同步，希望老师能在课堂上为我们拓展有关大作业的详细知识。
浙公网安备 33010602011771号