第一次博客作业(电梯)

引言

这是本学期第一次迭代大作业，虽然我并没有成功完成所有的编程代码，但我仍然学到很多知识，所以我对这次作业进行了复盘，希望能够在以后的作业中避免这次作业中出现的错误。

实验目标

本次电梯运行迭代大作业是为了初步培养我的面向对象的思维，从C语言的旧思维中跳跃出来，培养我对代码进行封装成类的思维，为以后面向对象的作业打下基础。

第一次实验迭代

题目要求
设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。
电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
使用键盘模拟输入乘客的请求，此时要注意处理无效请求情况，例如无效楼层请求，比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态，当没有请求时，电梯停留在当前楼层。
请编写一个Java程序，设计一个电梯类，包含状态管理、请求队列管理以及调度算法，并使用一些测试用例，模拟不同的请求顺序，观察电梯的行为是否符合预期，比如是否优先处理同方向的请求，是否在移动过程中处理顺路的请求等。为了降低编程难度，不考虑同时有多个乘客请求同时发生的情况，即采用串行处理乘客的请求方式（电梯只按照规则响应请求队列中当前的乘客请求，响应结束后再响应下一个请求），具体运行规则详见输入输出样例。

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例:
在这里给出一组输入。例如：

1
20
< 3,UP>
<5>
<6,DOWN>
<7>
<3>
end
输出样例:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door

类图

SourceMonitor分析

代码分析

1.功能介绍
核心功能：实现乘客对电梯的外部和内部需求，并且打印电梯运行信息
2.主要的方法和类
电梯类
这个类主要用于模拟电梯的运行，包含了电梯的基本属性和操作方法。
属性
minf：表示电梯所能到达的最小楼层。
maxf：表示电梯所能到达的最大楼层。
nowf：表示电梯当前所在的楼层。
方向：表示电梯的运行方向，初始值为 "IDLE"（静止）。
内部请求：一个 Queue 类型的队列，用于存储电梯内部乘客的请求楼层。
外部请求：一个 Queue<外部请求> 类型的队列，用于存储电梯外部乘客的请求，其中外部请求是一个静态内部类，包含楼层和方向两个属性。
方法
构造方法：
电梯(int minf, int maxf)：初始化电梯的最小楼层、最大楼层，将当前楼层设为最小楼层，方向设为静止，同时初始化内部请求和外部请求队列。
私有方法：
检查楼层有效性(int 楼层)：检查输入的楼层是否在电梯可到达的最小和最大楼层范围内，若不在则返回 false，否则返回 true。
上行()：将电梯当前楼层加 1，并输出当前楼层和运行方向（UP）。
下行()：将电梯当前楼层减 1，并输出当前楼层和运行方向（DOWN）。
开门()：输出开门信息，然后调用关门() 方法。
关门()：输出关门信息。
公有方法：
添加内部请求(int 楼层)：检查输入的楼层是否有效，若有效则将其添加到内部请求队列中，否则输出 “格式错误”。
添加外部请求(int 楼层, String 方向)：检查输入的楼层和方向是否有效，若有效则将其封装成外部请求对象添加到外部请求队列中，否则输出 “格式错误”。
检查是否有请求()：检查内部请求队列和外部请求队列是否为空，若至少有一个不为空则返回 true，否则返回 false。
处理请求()：处理电梯的请求，根据电梯当前的运行方向和请求队列中的请求，决定电梯的运行方向和是否开门，直到所有请求处理完毕。
Main 类
这个类是程序的入口，负责读取用户输入并调用电梯类的方法。
方法
main(String[] args)：
创建 Scanner 对象用于读取用户输入。
读取用户输入的最小楼层和最大楼层，创建电梯对象。
循环读取用户输入的请求，根据请求格式调用电梯类的添加内部请求或添加外部请求方法。
当用户输入 "end" 时，调用电梯类的处理请求方法处理所有请求。
关闭 Scanner 对象。
优点
结构相对清晰：类和接口数量仅为 1 ，每个类的方法数是 1.00 ，说明代码在结构组织上较为简单直接，没有过多复杂的类层次或大量方法交织，在一定程度上便于初步理解代码整体架构。
方法调用有一定规律：方法调用语句数为 50 ，表明代码在功能实现上通过合理的方法调用来组织逻辑，若方法划分合理，有助于代码的模块化和复用。
不足
注释严重缺乏：含注释行占比仅 0.6% ，这会使代码可读性大打折扣。
部分方法复杂度高：最复杂方法 Main.main() 行数达 134 ，最大复杂度为 6 ，平均复杂度也有 6.00 。复杂度过高的方法意味着代码逻辑可能过于冗长和嵌套，难以测试、调试和维护，违背了代码简洁性和可维护性原则。
代码深度和分支占比需关注：最大代码块深度为 6 ，分支语句占比 30.3% ，较深的代码块深度和一定比例的分支逻辑，可能导致代码执行路径复杂，降低代码的可理解性和可维护性，也增加了出现逻辑错误的风险。

第二次迭代代码分析

题目要求
对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，具体设计可参考如下类图。

电梯运行规则与前阶段单类设计相同，但要处理如下情况：

乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>
注意：本次作业类设计必须符合如上要求（包含但不限于乘客请求类、电梯类、请求队列类及控制类，其中控制类专门负责电梯调度过程），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次电梯程序提交到本次题目中测试）。

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例1:
在这里给出一组输入。例如：

1
20
< 3,UP>
<5>
<6,DOWN>
<7>
<3>
end
输出样例1:
在这里给出相应的输出。例如：

1
20
< 3,UP>
< 3,UP>
<5>
<5>
<5>
< 6,DOWN>
<7>
<7>
<3>
<22,DOWN>
<5,DOWN>
<30>
END
输出样例2:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Open Door # Floor 5
Close Door
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door

类图

SourceMonitor分析

Lines：代码共 317 行，有一定规模。
Statements：189 条语句，代码逻辑较丰富。
Percent Branch Statements：分支语句占比 20.6%，说明代码中条件判断（如 if、switch）较多。
Method Call Statements：133 次方法调用，代码模块间交互频繁。
Percent Lines with Comments：注释行占比 0.0%，严重缺乏注释，不利于代码理解与维护。
Classes and Interfaces：定义了 7 个类或接口，结构较复杂。
Methods per Class：平均每个类有 5.57 个方法，部分类功能可能过于集中。
Average Statements per Method：每个方法平均 3.33 条语句，整体方法简短，但存在个别复杂方法。
Line Number of Most Complex Method：最复杂方法位于 165 行，是 Controller.processRequests()，复杂度达 38，严重违背单一职责原则，可读性与维护性差。
Maximum Block Depth：最大代码块深度为 6，嵌套层次深，逻辑复杂。
Average Block Depth：平均块深度 2.58，代码结构存在一定嵌套。
Average Complexity：平均复杂度 2.41，整体复杂度尚可，但个别方法拉高了风险。
图表分析
Kiviat Graph
% Comments：注释占比为 0，代码可读性差。
Max Complexity：复杂度指标突出（如 Controller.processRequests() 复杂度 38），代码维护困难。
Max Depth：代码块深度指标表现不佳，嵌套层次影响逻辑清晰度。
Block Histogram
块深度为 2 的语句数最多，说明代码中存在较多两层嵌套结构，整体结构有优化空间。

代码分析

1.核心功能
在上次的作业的基础上，增加错误输入报错.
2.主要的方法和类
主要类
Direction 枚举类
定义电梯运行方向：UP（上行）、DOWN（下行）、IDLE（静止）。
State 枚举类
定义电梯状态：MOVING（移动中）、STOPPED（停止）。
ExternalRequest 类
表示外部请求，包含属性：
floor：请求楼层（Integer）。
direction：请求方向（Direction 枚举）。
方法：
ExternalRequest(Integer floor, Direction direction)：构造方法。
getFloor()：获取请求楼层。
getDirection()：获取请求方向。
RequestQueue 类
管理请求队列，包含属性：
internalRequests：内部请求队列（LinkedList）。
externalRequests：外部请求队列（LinkedList）。
方法：
addInternalRequest(int floor)：添加内部请求。
addExternalRequest(int floor, Direction direction)：添加外部请求。
getInternalRequests()、setInternalRequests()：操作内部请求队列。
getExternalRequests()、setExternalRequests()：操作外部请求队列。
Elevator 类
表示电梯，包含属性：
currFloor：当前楼层（int）。
dir：运行方向（Direction 枚举）。
state：状态（State 枚举）。
maxFloor：最大楼层（int）。
minFloor：最小楼层（int）。
方法：
Elevator(int minFloor, int maxFloor)：构造方法，初始化电梯。
moveUp()：电梯上行，更新楼层、方向和状态，输出当前楼层和方向。
moveDown()：电梯下行，逻辑类似 moveUp()。
openDoors()：打开电梯门，调用 closeDoors()。
closeDoors()：关闭电梯门，输出信息。
isValidFloor(int floor)：检查楼层是否在有效范围内。
一系列 getter 和 setter 方法（如 getCurrFloor()、setDir(Direction dir) 等）。
Controller 类
控制电梯逻辑，包含属性：
elevator：电梯对象（Elevator）。
requestQueue：请求队列对象（RequestQueue）。
方法：
Controller(Elevator elevator, RequestQueue requestQueue)：构造方法。
processRequests()：核心方法，循环处理请求队列。根据电梯方向优先处理同方向请求，无请求时切换方向。
hasHigherReq()：检查是否存在更高楼层的请求（内部或外部上行）。
hasLowerReq()：检查是否存在更低楼层的请求（内部或外部下行）。
其他空方法（如 determineDirection()、move() 等，未实现具体逻辑）。
Main 类
程序入口，包含方法：
main(String[] args)：读取用户输入，初始化 Elevator、RequestQueue 和 Controller，处理输入请求并调用 controller.processRequests()。
主要方法
Elevator.moveUp()：电梯上行逻辑，更新楼层、方向和状态，输出当前信息。
Elevator.moveDown()：电梯下行逻辑，类似 moveUp()。
RequestQueue.addInternalRequest(int floor)：添加内部请求到队列。
RequestQueue.addExternalRequest(int floor, Direction direction)：添加外部请求。
Controller.processRequests()：核心调度方法，处理所有请求，实现电梯运行规则。
Controller.hasHigherReq()：判断是否有更高楼层的请求（内部或外部上行）。
Controller.hasLowerReq()：判断是否有更低楼层的请求（内部或外部下行）。
Main.main(String[] args)：程序入口，处理输入输出和初始化对象。
不足：
缺乏注释：Percent Lines with Comments 为 0.0%，完全没有注释，导致代码逻辑难以理解，尤其是复杂方法（如 Controller.processRequests），后续维护和协作成本高。
方法复杂度高：Controller.processRequests 方法复杂度达 38，且最大代码块深度为 6，逻辑过于集中，违背单一职责原则，可读性和可维护性差。
条件判断密集：Percent Branch Statements 占比 20.6%，代码中条件判断过多，使逻辑流程不够清晰，增加理解难度。
代码结构优化不足：尽管平均方法语句数较少，但部分方法内部嵌套和逻辑复杂，且从块直方图看，存在较多两层嵌套结构，整体代码结构仍有优化空间。

第三次迭代代码分析

题目

对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，具体设计可参考如下类图。

电梯运行规则与前阶段相同，但有如下变动情况：

乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
注意：本次作业类设计必须符合如上要求（包含但不限于设计电梯类、乘客类、队列类以及控制类），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次及第二次电梯程序提交到本次题目中测试）。

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<请求源楼层，请求目的楼层>，其中，请求源楼层表示乘客发起请求所在的楼层，请求目的楼层表示乘客想要到达的楼层。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：

1
20
<5,4>
<5>
<7>
end
输出样例1:
在这里给出相应的输出。例如：

1
20
<5,9>
<8>
<9,3>
<4>
<2>
end
输出样例2:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Current Floor: 8 Direction: UP
Open Door # Floor 8
Close Door
Current Floor: 9 Direction: UP
Open Door # Floor 9
Close Door
Current Floor: 8 Direction: DOWN
Current Floor: 7 Direction: DOWN
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Open Door # Floor 4
Close Door
Current Floor: 3 Direction: DOWN
Current Floor: 2 Direction: DOWN
Open Door # Floor 2
Close Door
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Current Floor: 8 Direction: UP
Current Floor: 9 Direction: UP
Open Door # Floor 9
Close Door
Current Floor: 8 Direction: DOWN
Current Floor: 7 Direction: DOWN
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door

类图

SourceMonitor分析

Lines: 273：代码行数适中，但仍需关注结构清晰度。
Statements: 162：语句数量较多，逻辑有一定复杂度。
Percent Branch Statements: 22.8：分支语句占比较高，表明代码中条件判断（如 if、switch）频繁，逻辑分支复杂。
Method Call Statements: 102：方法调用频繁，模块间交互多，需确保调用逻辑清晰。
Percent Lines with Comments: 2.6：注释极少，严重影响代码可读性与可维护性。
Classes and Interfaces: 1：若实际代码包含多个类（如之前的 Elevator、RequestQueue 等），则可能是统计工具误判；若确实仅一个类，则违背 “单一职责” 原则，功能过于集中。
Methods per Class: 26.00：若一个类包含 26 个方法，明显违背单一职责，应拆分功能。
Average Statements per Method: 6.00：方法平均语句数尚可，但存在个别复杂方法（如 Main.main()）拉高整体复杂度。
Line Number of Most Complex Method: 236、Name of Most Complex Method: Main.main()：main 方法复杂度最高（Maximum Complexity: 7），代码行数多，逻辑复杂。
Maximum Block Depth: 5、Line Number of Deepest Block: 143：最大代码块深度为 5，嵌套层次深，逻辑理解困难。
Average Block Depth: 1.98：平均块深度接近 2，整体结构存在一定嵌套，需优化。
Average Complexity: 7.00：平均复杂度较高，代码整体维护难度大。
图表分析
Kiviat Graph：
% Comments 低，注释严重不足。
Avg Complexity 和 Max Complexity 指标突出，代码复杂度高，维护困难。
Block Histogram：
块深度为 1 和 2 的语句数较多，但也存在不少深度更高的块，表明代码结构有优化空间，应减少深层嵌套。

代码分析

1.代码需求
对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类。
2.代码类和主要方法
Passenger（乘客类）
功能：封装乘客的出发楼层和目标楼层。
属性：
sourceFloor：出发楼层。
destinationFloor：目标楼层。
方法：
Passenger(int sourceFloor, int destinationFloor)：构造函数，初始化出发和目标楼层。
getSourceFloor()：获取出发楼层。
getDestinationFloor()：获取目标楼层。
RequestQueue（请求队列类）
功能：管理电梯的内部请求（楼层）和外部请求（乘客）队列。
属性：
internalRequests：内部请求队列（Queue）。
externalRequests：外部请求队列（Queue）。
方法：
addInternalRequest(int floor)：添加内部请求（楼层）。
addExternalRequest(Passenger passenger)：添加外部请求（乘客）。
peekNextInternalRequest()：查看下一个内部请求。
peekNextExternalRequest()：查看下一个外部请求。
getNextInternalRequest()：取出下一个内部请求。
getNextExternalRequest()：取出下一个外部请求。
hasInternalRequests()：判断是否有内部请求。
hasExternalRequests()：判断是否有外部请求。
getInternalRequests()：获取内部请求队列。
getExternalRequests()：获取外部请求队列。
Elevator（电梯类）
功能：表示电梯，处理电梯的移动、开关门等操作。
属性：
currentFloor：当前楼层。
direction：运行方向（IDLE、UP、DOWN）。
minFloor：最小楼层。
maxFloor：最大楼层。
方法：
Elevator(int minFloor, int maxFloor)：构造函数，初始化电梯参数。
getCurrentFloor()：获取当前楼层。
getDirection()：获取运行方向。
setDirection(String direction)：设置运行方向。
moveUp()：电梯上行，更新楼层和方向并输出。
moveDown()：电梯下行，更新楼层和方向并输出。
openDoor()：打开电梯门，调用closeDoor()。
closeDoor()：关闭电梯门并输出。
isValidFloor(int floor)：检查楼层是否在有效范围内。
ElevatorController（电梯控制类）
功能：控制电梯的请求处理逻辑，调度电梯运行。
属性：
elevator：电梯对象（Elevator）。
requestQueue：请求队列对象（RequestQueue）。
方法：
ElevatorController(Elevator elevator, RequestQueue requestQueue)：构造函数，初始化电梯和请求队列。
processRequests()：核心方法，循环处理内部和外部请求，根据电梯方向调度。
hasHigherRequest()：判断是否存在更高楼层的请求（内部或外部）。
hasLowerRequest()：判断是否存在更低楼层的请求（内部或外部）。
Main（主类）
功能：程序入口，处理用户输入并启动电梯控制逻辑。
方法：
main(String[] args)：读取用户输入，创建电梯、请求队列和控制器，解析输入并添加请求，最后调用controller.processRequests()处理请求。
核心方法
Elevator.moveUp() 和 Elevator.moveDown()：实现电梯的上下移动，更新楼层和方向，并输出当前状态。
RequestQueue.addInternalRequest() 和 RequestQueue.addExternalRequest()：分别向内部和外部请求队列添加请求。
ElevatorController.processRequests()：核心调度方法，根据电梯当前方向优先处理同方向请求，无请求时切换方向，控制电梯的移动和开关门。
Main.main(String[] args)：程序入口，处理输入输出，初始化系统并启动请求处理流程。
不足
1.缺乏注释
代码中几乎没有注释，难以理解类、方法的功能及逻辑，不利于后续维护和协作。例如，ElevatorController 类的 processRequests 方法逻辑复杂，无注释难以快速理解其调度逻辑。
2.代码重复与逻辑复杂
ElevatorController 类中处理上行（UP）和下行（DOWN）的逻辑存在大量重复代码。此外，processRequests 方法嵌套层次多，可读性差，没做到代码简洁和单一职责原则。
3.输入验证不健壮
在 Main 类中，仅简单检查楼层是否在有效范围内，但对用户输入非数字、格式严重错误等情况未做处理，可能导致程序崩溃。
封装不足
RequestQueue 类的 getInternalRequests 和 getExternalRequests 方法直接返回 Queue 实例，外部可直接修改队列，破坏了封装性。
4.状态管理简单
电梯状态仅通过 direction 字段（IDLE、UP、DOWN）体现，未细化区分 “开门”“关门”“移动中” 等状态，逻辑表达不够清晰。
5.可测试性差
ElevatorController 与 Elevator、RequestQueue 耦合紧密，难以单独对 ElevatorController 进行单元测试（如模拟电梯状态或请求队列）。

心得

经过这次实验，我深刻认识到我的基础的不足，如代码的判断条件过多，导致代码冗余，可读性不高，后期对代码的维护难度和成本也更高。在设计方面，我是参考老师给的类图进行编译，缺少自我思考设计，导致我思维稍微固化，在接下来实验中，我将对实验题目进行自己设计类图并进行编译，并且在编译过程中尽可能的保证代码的可读性，可维护性，增强我的Java能力。

posted @ 2025-04-19 21:19 萧辰1 阅读(45) 评论(0) 收藏举报

刷新页面返回顶部

第一次博客作业(电梯)

引言

实验目标

第一次实验迭代

类图

SourceMonitor分析

代码分析

第二次迭代代码分析

类图

SourceMonitor分析

代码分析

第三次迭代代码分析

题目

类图

SourceMonitor分析

代码分析

心得

公告