题目集5~7第一次Blog作业

前言
面向对象的第一阶段结束了，本次的作业为电梯程序对我来说难度较大一直未能理解其全部运行逻辑导致只能一部分答案正确，在本次作业中所涉及到的知识点：
1、类(Class)的定义和使用。2、枚举(Enum)的定义和使用。3、ArrayList集合的使用。4、List接口的使用。5、String类的字符串处理方法。6、正则表达式匹配(matches方法)。7、字符串替换(replaceAll方法)。8、字符串分割(split方法)。9、LinkedList的添加(add)、移除(remove)、检查(contains)通过索引访问(get(i))10、
第一次电梯程序
作业要求：设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。
设计与分析：
类图：

源码分析：

1、高复杂度方法: processRequests()方法复杂度16，远高于推荐值(通常建议不超过10)
2、深度嵌套: 最大嵌套深度达到7层，表明可能存在过度嵌套的逻辑
心得：对于processRequests()方法复杂度过高是因为我对确定电梯接下来要前往的楼层的规则理解不够透彻，有多余的判断。对于深度嵌套，可以用嵌套的代码块提取为独立的方法，但本人未能实现，在修改过程中有许多报错，解决后输入输出变得一塌糊涂，对这方面的修改基础过于单薄，往后的学习还需继续努力。
踩坑心得：
只能通过样例的输入输出测试，提交后发现无法通过测试点，在测试其他输入测试时发现方向的判断并非时当前楼层所在方向而是后续前往的方向


通过上图可知晓（黑底为样例），但我无法解决这一问题，因为输入的要求为<3,down>但在结果中电梯此时虽然向上但后续是向下运行所以此时的<3,down>可以满足，我的判断则是当前电梯的方向，如果仅仅改变对方向的判断前后顺序又会导致其他样例通过不了，在这里的逻辑我没有弄清楚，导致此题未能做出来。
第二次电梯运行程序
作业要求：对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，具体设计可参考如下类图。
设计与分析：
类图：

源码分析：

1、识别Main类中的功能组，为每组创建专门的类，遵循单一职责原则(SRP)
2、最大嵌套深度达到6层，表明存在过度嵌套的代码块
心得：在写此代码中仅仅是依照类图的要求对类进行设计编写，并没有怎加心得类在其中，导致Main类中的功能组过多，但本人在阅读Main类后找不到可以分出来的类对分析出来的问题无法解决。与第一次同样的问题是过度嵌套，竭尽全力也只能减掉一层，在修改就会导致最基本的样例出现错误。
踩坑心得：
输入/输出样例：


我的输出（不同点）：

通过对比可知，我在判断时采取的方法是只读取ArrayList中的第一项，当第一项需求被满足后将后面一项移到第一项，而第一项分为内部和外部，在电梯运行到1楼后内部第一项应变为<3>外部第一项为<5,up>此时按照正确的逻辑电梯应在3楼停一下然后再前往5楼，但可能是对第一项的判定有误，因为在内部队列中<3>为第3项，而外部队列中<5,up>为第2项，这导致变动后队列中的第一项出现错误，所以我对队列第一项的移动进行修改但无济于事，其后我的想法是程序并没有对内部和外部的第一项进行比较从而确定是先执行内部还是外部队列，仅仅只是按照顺序执行乘客要求，但通过下图：

我的程序可以通过PTA的一个样例测试，这就说明我对队列第一项的处理并没有问题，到此我已找不到问题的点，使我的第二次电梯程序也未能完成。
第三次电梯程序
作业要求：对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，具体设计可参考如下类图。
电梯运行规则与前阶段相同，但有如下变动情况：乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
设计与分析：
类图：

源码分析：

1、方法分布不均: 平均每个类含12个方法，远超理想值(5-8个)
2、Controller.move()方法13的复杂度(>10即为危险信号)
3、极端嵌套: 最大深度达7层，可读性差且维护困难
心得：对于方法分布不均未能有有效解决方案，我对于类中方法的编写完全来自与作业要求中的类图，我现在还未能掌握独自对较复杂的类进行设计，这方面的能力在后续的学习中要尽快加强，其中的深度嵌套
可能源于过多的null检查和异常处理，但在去除一些判断后会导致输出错误，准备用枚举法一个一个试，但数量太多放弃了。
踩坑心得：

通过对比可知，电梯在5楼停了两次，通过Debug调试也未能找到原因，想自己设计一些输入样例，但自己推出来的结果与实际输出也不符，至于是我逻辑出的问题导致预期输出错误还是程序运行错误未能得知。至此第三次作业out。
改进建议
第一次：
1.重点关注Elevator.processRequests()方法：这是复杂度最高的方法(16)，很可能包含深度嵌套。
考虑将请求处理逻辑分解为多个小方法。
2. 引入注释：当前代码注释率为0%，重构时添加解释性注释。
3.考虑状态模式：电梯逻辑通常适合用状态模式实现，减少条件判断。
4. 逐步重构：不要一次性重构所有嵌套，每次解决一个层级确保有良好的测试覆盖。
第二次：

1. 重构Main类
   拆分职责: 将Main类中的逻辑拆分到多个专门的类中
   提取方法: 将main()方法中的逻辑提取到多个小方法中。
2. 减少嵌套深度
   应用卫语句: 在深度嵌套的条件判断中使用提前返回。
3. 增加注释
   为每个类和方法添加Javadoc注释，为复杂逻辑添加行内注释。

第三次：

1. 减少嵌套深度（当前最大7层）
   采用技术：
   卫语句(Guard Clauses)
   提前返回(Early Returns)
   条件反转
   2、增强代码文档
   文档标准：
   每个类和方法添加Javadoc（使用/** */）
   复杂算法添加行内注释
   关键决策点添加注释
   这些建议中除了增加注释可以现在完成，其他所述很多读不懂，听都没听过（这些建议是通过CSDN博客的介绍我浅显阅读了一下SourceMonitor的报表，然后查询了一些资料得出的），对于类的重构我有信心在接下来的学习中有长足的进步。

总结：
这次的电梯作业让我了解到了面向对象程序设计这门课的难度，此次作业从第一次设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。到第二次进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类。到最后一次加入乘客类（Passenger），取消乘客请求类。一次次的迭代让我看到了一个程序是如何变得更完美，更能满足各种需求。从刚接触到电梯连ArrayList都不知道，到结束时学会了使用ArrayList虽然不是很熟练但也算是入门了，对字符串的处理能力也得到了提升，学习了许多字符串的处理方法包括但不限于——字符串比较（compareTo）、获取指定位置字符（charAt（））、字符串分割（split）等等。除了在Java程序编写上的知识，通过一次完整阶段的学习，我学会了使用一些工具，如SourceMonitor对程序进行分析，接下了就是学习如何看懂SourceMonitor的分析报表，争取下一次不需要用DeepSeek帮我分析。如使用IDE进行DeBug调试，针对某一段程序深入了解其中每个变量的变化，方法的调用。通过这次作业发现自己对Java语言的学习远远不够很多Java自带的方法都不知道，如何进行类设计，尤其是多个较复杂的类怎么设计，类与类之间的关系是什么，类之间怎么调用都是接下来要学习的重中之重，对于Java语言最基础的程序设计要自学，通过学校发的教材将前面的基础知识补上，然后结合网课对对象和类，面向对象再次深度学习，这段时期的学习对继承和多态掌握度远远不够，线上线下的课都听不太懂，要结合教材找找其他网课系统学习，不会的要积极向老师提问。对老师的建议就是在课上讲知识点时能多举一些生动易懂的例子，能多一些对PTA题目的讲解。对于试验系统希望老师能改进一下，比如在中文输入时老是输入到一半就直接把拼音输入进去了，我想可能是自动保存的原因，还有就是实验系统的字体能不能改一下不要那么又小又挤。