第一次Blog作业：电梯分析

前言：虽然这几次的电梯问题并没有及时的完成，在其中遇到了许多困难，但是后面有继续完成。总结三次电梯题目。
第一次的电梯题目知识点有熟悉类的声明、创建与使用方法，类的构造方法的定义与使用方法，类的成员变量、成员方法的定义与使用方法。因为是第一次遇到这种大题量的作业，这个题目的题量对于我来说是比较大的。
难度也是偏高。
第二次的电梯题目知识点有了解类间关系，根据所给的类图来设计多个类，设计类时必须遵循 单一职责原则(SRP) ，这次的电梯题要对第一次电梯题进行迭代处理，该题目是基于第一次的基础上进行类的设计，由于第一次的题目没有及时做完会导致第二次进行比较缓慢，对于我来说题目量也比较大，难度比第一次会好一点。
第三次的电梯题目类设计的数量比上次多，关系也更加复杂，不仅要了解一种求圆周率的新方法——蒙特卡洛仿真方法，还要对电梯题再次进行迭代。由于外部请求由原来的初始楼层和方向变成了初始楼层和目标楼层，所以逻辑上变得更加复杂。第三次的题目会更加的难。
设计与分析：
第一次电梯原题：



第一次电梯的类图：

分析：
我先对该类图进行分析，这是一个关于电梯系统的类图，主要包含 Elevator 类和 Main 类 。Elevator 类用于描述电梯的属性和行为，Main 类可能是程序的入口点，用于启动和控制整个电梯系统相关逻辑。
Elevator 类分析
属性
min：类型为 int ，初始值为 1 ，表示电梯可到达的最小楼层。
max：类型为 int ，表示电梯可到达的最大楼层。
current：类型为 int ，表示电梯当前所在楼层。
direction：类型为 String ，用于表示电梯运行方向（如 “up” 或 “down” ）。
isRun：类型为 boolean ，表示电梯是否正在运行。
internal：类型为 List ，用于存储电梯内部乘客请求到达的楼层列表。
externalUp：类型为 List ，存储电梯外部向上运行方向的请求楼层列表。
externalDown：类型为 List ，存储电梯外部向下运行方向的请求楼层列表。
up：类型为 String ，可能用于表示与向上运行相关的某种标识或状态 。
down：类型为 String ，可能用于表示与向下运行相关的某种标识或状态 。
方法
构造方法 Elevator()：用于初始化 Elevator 对象。
Getter 和 Setter 方法：如 getMax()、setMax(int max) 等，用于获取和设置各个属性的值，这是面向对象编程中封装属性的常见做法，保证属性的访问控制。
addRequest(int floor, String dir)：用于添加电梯请求，参数 floor 是请求的楼层，dir 是请求方向（可能是 “up” 或 “down” ）。
move()：用于实现电梯的移动逻辑，应该是根据请求和当前状态来更新 current 楼层属性。
requests()：可能用于获取当前所有的请求列表，返回值类型为 List 。
checkStop()：用于检查电梯是否需要在当前楼层停靠，返回 boolean 类型，判断是否满足停靠条件。
processStop()：处理电梯停靠时的相关逻辑，比如开门、上下乘客等操作。
controlDirection()：控制电梯运行方向，根据请求情况和当前状态调整 direction 属性。
upRequest()：可能用于判断是否有向上的请求，返回 boolean 类型。
Main 类分析
属性
switchState：类型为 boolean ，初始值为 false ，可能用于表示电梯系统中某个开关（如总电源开关等）的状态。
方法
main(String[] args)：Java 程序的入口方法，程序从这里开始执行，在这个方法中应该会创建 Elevator 对象，并调用相关方法来启动和控制电梯系统的运行逻辑。
SourceMonitor表格：

我们可以得到数据：
代码行数达 167 行，语句有 74 条，含 4 个类或接口，平均每个类约 2.75 个方法，方法平均语句数 5.09 条 。
分支语句占比 18.9% ，方法调用语句 27 条，注释行仅占 3.0% ，注释相对匮乏。
由此可以看出一些不足：
注释严重匮乏：含注释行的比例仅 3.0% 。在大型项目或多人协作中，缺少注释会使代码可读性变差，后期维护人员难以快速理解代码逻辑，增加维护成本和出错风险。
复杂度集中问题：存在最复杂方法 ElevatorSystem.processRequests() ，其复杂度较高可能导致代码理解、测试和修改困难。高复杂度方法往往隐藏较多潜在 bug，且修改时容易影响其他功能。
分支语句占比仍有优化空间：虽然 18.9% 的分支语句占比不算极高，但过多分支会使代码逻辑变得复杂，降低可读性和可维护性，可考虑优化逻辑结构，减少不必要分支。

第二次电梯原题：



第二次电梯的类图：

分析：
该电梯设计通过不同类之间的属性关联和方法调用，构建起一个完整的电梯运行控制逻辑。类与类之间通过聚合、依赖等关系进行交互，实现电梯状态管理、请求处理等功能。
Elevator类
功能：作为核心实体类，封装了电梯的状态信息（当前楼层、运行方向、状态等）和操作方法。通过构造函数可设置电梯运行的楼层范围，各类 getter 和 setter 方法方便对电梯属性进行访问和修改，isValidFloor 方法用于校验楼层的有效性。
关系：与 Direction 枚举类、State 枚举类存在关联，用于定义电梯的运行方向和状态。
Direction枚举类
功能：定义电梯可能的运行方向，为 Elevator 类和 ExternalRequest 类提供方向标识，使系统对电梯运行方向的表达更清晰、规范。
关系：被 Elevator 类和 ExternalRequest 类引用。
State枚举类
功能：界定电梯的运行状态，帮助系统判断电梯是处于移动还是停止状态，是电梯逻辑控制的重要依据。
关系：被 Elevator 类引用。
ExternalRequest类
功能：用于封装来自电梯外部（楼层按钮）的请求信息，包括请求楼层和请求方向，方便系统对外部请求进行统一管理和处理。
关系：依赖 Direction 枚举类定义请求方向，在系统中作为请求队列的组成部分。
Controller类
功能：作为系统的控制中心，协调 Elevator 类和 RequestQueue 类。通过其方法实现对电梯请求的处理、运行方向的确定、电梯移动及开关门等操作逻辑的控制。
关系：聚合了 Elevator 类和 RequestQueue 类实例，通过对这两个类的操作来实现整体控制功能。
RequestQueue类
功能：负责管理电梯的内外部请求队列，分别用链表存储内部请求（电梯内按钮）和外部请求（楼层按钮），提供添加、获取请求列表等方法，便于 Controller 类进行请求处理。
关系：与 ExternalRequest 类和 Integer 类型关联，用于存储请求信息，同时被 Controller 类引用。
Main类
功能：程序的入口点，在该类的 main 方法中通常会进行系统初始化，如创建 Controller、Elevator 等关键对象实例，启动电梯系统运行逻辑。
SourceMonitor表格：

代码统计：243 行，139 条语句，分支语句占 19.4% ，方法调用 71 条，注释行占 2.9% ，有 2 个类或接口 ，类均方法数 11，方法均语句数 6 。
由此可以看出：
复杂度偏高：最大复杂度 12 、平均复杂度 12 ，以及较大的深度值，意味着代码逻辑可能较为复杂，理解、调试和修改时容易出错，可维护性差。
注释严重缺乏：注释行占比仅 2.9% ，对代码逻辑的解释说明过少，不利于团队协作及后期代码维护，其他人阅读代码时难以快速把握代码意图。
对于该代码的设计基本思路如下：整体由 Elevator、Controller 和 Main 类构成。Main 类负责读取用户输入，包含电梯的最小与最大楼层以及外部和内部请求，对格式错误的请求会跳过。Elevator 类存储电梯状态和请求列表，将请求添加到相应列表。Controller 类是核心，在 processRequires 方法的无限循环中处理请求，先打印当前楼层和方向，若有请求则开门并移除。

第三次电梯原题：




分析：
先对类图进行分析：
此次设计围绕电梯系统建模，涵盖电梯状态管理、运行控制、乘客请求处理等功能。通过定义不同类及类间关系，实现对电梯运行逻辑和乘客请求调度的抽象与封装 。
Direction枚举类
定义电梯运行方向常量，包括UP（向上）、DOWN（向下） 、IDLE（空闲） ，用于表示电梯运行方向状态。
State枚举类
定义电梯状态常量，MOVING（运行中）、STOPPED（停止），用于标识电梯当前运行状态。
Elevator类
属性：记录当前楼层（currentFloor）、运行方向（direction）、状态（state）、最大楼层（maxFloor）、最小楼层（minFloor） 。
方法：构造方法用于初始化楼层范围；提供获取 / 设置电梯实例、楼层、方向、状态等信息的方法，还有判断楼层是否有效的方法，实现对电梯基本属性的管理和操作。
Controller类
属性：关联Elevator对象和RequestQueue对象，用于控制电梯运行和处理请求队列。
方法：构造方法用于初始化；包含获取 / 设置电梯和请求队列、处理请求、确定运行方向、判断是否该停、获取下一楼层等方法，实现对电梯运行逻辑的控制。
Passenger类
属性：记录乘客出发楼层（sourceFloor）和目的楼层（destinationFloor）。
方法：构造方法用于初始化；提供获取 / 设置出发楼层和目的楼层的方法，封装乘客请求信息。
RequestQueue类
属性：使用链表分别存储内部请求（internalRequests）和外部请求（externalRequests）。
方法：构造方法用于初始化；提供获取请求队列实例、获取 / 设置内外部请求、添加内外部请求的方法，实现对乘客请求的存储和管理。
类间关系
依赖关系：Elevator类依赖Direction和State枚举类来确定运行方向和状态；Controller类依赖Elevator和RequestQueue类来实现控制逻辑；RequestQueue类依赖Passenger类来管理请求。
关联关系：Controller类与Elevator类和RequestQueue类存在关联，用于控制电梯和处理请求队列；RequestQueue类与Passenger类关联，用于存储乘客请求 。
由于最后并没有成功写出该题目代码，对于第三次电梯设计还在学习当中。

踩坑心得：
对于第一次遇见这种大规模的作业，其实我有点手足无措，开始把请求的过滤写完之后，我就开始分析内部电梯逻辑的实现。首当其冲的就是能够分析明白电梯的运行规则，这个对我来说就有点困难。后来，我们需要书写电梯类Elevator来进行调度电梯，又因为第一次的电梯题目没有老师给出类图，所以会导致做的时候不知道从哪里开始，这样子就会浪费太多时间在开头。
第二次有了老师给的类图就会好很多，知道如何开始动手写代码，以及类的设计等等，写出来的程序并没有严格按照老师给的类图来设计，因为电梯要根据下一个目标楼层移动，而很多方法都没有参数，没有参数就要在方法内再确定目标楼层，但每次移动后目标楼层都会改变，这就导致每个方法中的目标楼层都不一致，所以后面一直在进行修改，导致最后没有按时完成该题目。
对于第三次题目，我已经对电梯的处理方法有了深刻的了解，并在一次次的调试中解决问题，目前还在考虑第三次电梯问题。
还有一个很重要的是养成写注释的习惯:因为代码十分复杂, 所以该题目通常要花几天的时间才能完成, 而第二天的时候继续编写经常会发现忘记了原来某些已经写过的方法是什么作用, 所以建养成写注释的习惯, 便于回忆和思考也更便于维护。
以及当我们面对新的东西，不应该一味的等老师来讲解，我们可以自己去网上学习了解，这样子可以节省大量的时间，让进度不这么赶，而到后面出现无法及时完成的情况。

改进建议：
1.我的代码中注释严重不足，极大地阻碍了代码的理解和维护。为提高代码的可读性，应在类、方法和关键代码段前添加详细注释，说明其功能、输入输出参数及实现思路，对于复杂逻辑部分，需详细解释其原理。在修改代码时，我要及时更新相应注释，确保注释与代码逻辑一致，避免因注释与代码不符导致误解和错误。
2.考虑使用更灵活的数据结构和算法来处理请求，提高代码的扩展性和性能。提取重复的代码逻辑到独立的方法中，提高代码的复用性。
3.在写代码之前要先搞明白需求，才能进行设计代码，先构思好再进行写代码以及设计，在这几次作业中我都是直接就开始写代码，按照老师给的类图，后面会发现并不能弄懂每个类之间的关系等等，代码也不能达到应有的要求，需要更多时间的修改甚至是重新写过。

总结：
因为这三次题目我都没有通过，并且现在还在研究第三次的电梯运行，但是也学习到了很多，我深入理解并实践了类的设计，从最初单个 Elevator 类的设计，到后续多个类协作完成复杂功能，学会根据不同功能合理划分职责并封装到各个类中。接触并学会了队列这种数据结构在面向对象编程中的基本用法，了解到队列适合处理需要不断改变固定位置（队首和队尾 ）的情况，比如在电梯调度中处理请求队列，通过队列来管理内外请求，优化了数据处理流程。在这一大阶段的学习中有过迷茫，由于强度一下子就上来了，不认真的学习以及课后真正的花时间在这个的自学上面是很困难去完成这几次的题目，由于第一次开始之前并没有花足够多的时间进行学习会导致始终比其他人慢一步，进而影响到自己的心态去急躁，我需要从里面及时的调整好自己的心态以及态度，后面开始花更多的时间在其中，线上线下一起学习，去有更多的实际操作，也不局限于只听不做，我认为只有自己去做了才能够进步，还有就是要多问因为很多同学是做出来的，自己想很久还不如问一下同学能不能解决自己遇到的问题，这是一种非常方便的方法去快速的解决自己的问题，无论问谁，而不是自己一个人死磕。
这次阶段的学习是比较痛苦的每天都在不会做的焦虑中度过，但是其实用心花时间去学还是可以弄懂的，中途多少会有些崩溃，但是也让我明白了java不是这么简单就能学会的，我们需要花费大量的时间，也让我重新开始深思自己应该如何去做，为了以后阶段的学习需要更加用心认真。
对课程的建议：希望能够让我们去了解一些基础的知识，以及线上一些基础题的测试，或者渠道，能够有更多生活中的实例与课程相结合。实验的测试点可以增加一点，这样子可以更加清楚的知道问题出在哪里，从而进行修改。