第一次blog大作业分析
前言
通过几周对java的学习,迎来了第一次blog分析作业,这三道题目围绕单部电梯调度程序逐步展开,难度呈递进关系。
题目一要求设计一个基础的电梯类,实现基本的调度功能,包括处理乘客请求、控制电梯运行方向和状态等,同时需要处理无效请求并考虑电梯的空闲状态。该题着重考查了面向对象编程的基础知识,为后续更复杂的设计奠定了基础。
难度:中等
题目二则在前一题的基础上,对电梯调度程序进行迭代性设计,遵循单一职责原则(SRP),将电梯类的职责进行拆分,设计出电梯类、乘客请求类、队列类以及控制类,同时还需处理乘客请求楼层数有误和连续相同请求等特殊情况,这对代码的设计模式和逻辑处理能力提出了更高的要求。
难度:困难
题目三进一步迭代,引入乘客类并取消乘客请求类,同时改变了外部请求的输入格式和处理方式,要求在电梯处理外部请求后,将请求目的楼层加入内部队列。这不仅考验了对类的设计和职责划分的理解,还需要开发者具备灵活处理业务逻辑变化的能力。
难度:困难
通过对这三道题目的分析,我们可以清晰地看到从基础功能实现到遵循设计原则优化,再到应对业务需求变化的整个开发过程。这不仅有助于提升我们的编程技能,还能培养我们在面对复杂问题时的分析和解决能力。
设计与分析
1.第一次大作业
(1)题目
设计一个电梯类,具体包含电梯的最大楼层数、最小楼层数(默认为1层)当前楼层、运行方向、运行状态,以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列,其中,电梯外部请求队列需要区分上行和下行。
电梯运行规则如下:电梯默认停留在1层,状态为静止,当有乘客对电梯发起请求时(各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮),电梯开始移动,当电梯向某个方向移动时,优先处理同方向的请求,当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时,如果有新的请求,就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时,检查当前是否有请求(访问电梯内请求队列和电梯外请求队列),然后据此决定移动方向。每次移动一个楼层,检查是否有需要停靠的请求,如果有,则开门,处理该楼层的请求,然后关门继续移动。
使用键盘模拟输入乘客的请求,此时要注意处理无效请求情况,例如无效楼层请求,比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态,当没有请求时,电梯停留在当前楼层。
请编写一个Java程序,设计一个电梯类,包含状态管理、请求队列管理以及调度算法,并使用一些测试用例,模拟不同的请求顺序,观察电梯的行为是否符合预期,比如是否优先处理同方向的请求,是否在移动过程中处理顺路的请求等。为了降低编程难度,不考虑同时有多个乘客请求同时发生的情况,即采用串行处理乘客的请求方式(电梯只按照规则响应请求队列中当前的乘客请求,响应结束后再响应下一个请求),具体运行规则详见输入输出样例。
输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。
电梯内乘客请求格式:<楼层数>
电梯外乘客请求格式:<乘客所在楼层数,乘梯方向>,其中,乘梯方向用UP代表上行,用DOWN代表下行(UP、DOWN必须大写)。
当输入“end”时代表输入结束(end不区分大小写)。
输出格式:
模拟电梯的运行过程,输出方式如下:
运行到某一楼层(不需要停留开门),输出一行文本:
Current Floor: 楼层数 Direction: 方向
运行到某一楼层(需要停留开门)输出两行文本:
Open Door # Floor 楼层数
Close Door
输入样例:
在这里给出一组输入。例如:
1
20
❤️,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
(2)题目分析
知识点
类的设计与封装:设计一个电梯类,将电梯的属性(如最大楼层数、最小楼层数、当前楼层、运行方向、运行状态)和行为(处理请求、移动、判断停靠等)封装在类中,体现面向对象编程的封装特性。
数据结构运用:使用队列数据结构存储电梯内部和外部的乘客请求,理解队列的基本操作(如入队、出队),以实现请求的顺序处理。
条件判断与循环:运用条件判断语句(如if - else)判断电梯的运行方向、是否停靠等逻辑;通过循环(如while循环)持续处理请求,直到输入结束。
输入输出处理:掌握从控制台读取用户输入的方法,并按指定格式解析输入内容;同时,学会按要求格式输出电梯的运行状态。
难度:中等难度。题目对电梯运行规则描述详细,输入输出格式明确,基础编程知识的应用较为直接,但需要对面向对象编程和基本数据结构有一定理解,能够将业务逻辑转化为代码实现。
设计方法与类
设计电梯类:包含电梯相关的属性和方法。属性用于记录电梯状态,方法实现电梯的移动、请求处理、方向判断、停靠判断等功能。
主程序类:负责读取用户输入,创建电梯对象,并将请求传递给电梯对象进行处理,同时控制程序的流程。
(3)
- 代码规模相关
- Lines:代码行数,该文件总共有 150 行代码。
- Statements:语句数,文件中包含 97 条语句 。
- 代码结构相关
- Percent Branch Statements:分支语句所占百分比,为 27.8% ,反映代码中 if、switch 等分支语句的比例情况。
- Method Call Statements:方法调用语句数,共 43 条,统计代码中调用其他方法的语句数量。
- Percent Lines with Comments:含注释行的百分比,为 1.3% ,表示代码中注释行在总行数里的占比。
- Classes and Interfaces:类和接口数量,该文件包含 3 个类或接口 。
- Methods per Class:平均每个类的方法数,为 3.67 ,通过方法总数除以类的数量得出。
- Average Statements per Method:每个方法平均语句数,是 6.64 ,由语句总数除以方法总数得到。
- Line Number of Most Complex Method:最复杂方法所在行号,最复杂方法在第 69 行 。
- Name of Most Complex Method:最复杂方法名称,为 Elevator.move() 。
- Maximum Complexity:最大复杂度,为 13* ,衡量方法复杂程度的指标,值越大表示方法越复杂。
- Line Number of Deepest Block:最深代码块所在行号,在第 82 行 。
- Maximum Block Depth:最大代码块深度,为 6 ,表示代码中嵌套结构(如循环、条件语句嵌套 )的最大层数。
- Average Block Depth:平均代码块深度,是 2.54 ,反映代码整体的嵌套复杂程度。
- Average Complexity:平均复杂度,为 3.82* ,对文件中所有方法复杂度求平均,体现代码总体复杂程度。
- 复杂方法列表
- 列出了不同类中较复杂的方法,以及其复杂度(Complexity)、语句数(Statements)、最大深度(Max Depth)和方法调用数(Calls) 。例如 Elevator.move() 方法,复杂度为 13* ,有 21 条语句,最大深度为 6,方法调用数为 9 。
- 代码块深度统计
- 按代码块深度(Block Depth )分类,统计对应深度下的语句数量(Statements) 。如深度为 0 的代码块有 5 条语句,深度为 1 的有 19 条语句等。
2.第二次大作业
(1)题目
对之前电梯调度程序进行迭代性设计,目的为解决电梯类职责过多的问题,类设计要求遵循单一职责原则(SRP),要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类,具体设计可参考如下类图。
电梯运行规则与前阶段单类设计相同,但要处理如下情况:
乘客请求楼层数有误,具体为高于最高楼层数或低于最低楼层数,处理方法:程序自动忽略此类输入,继续执行
乘客请求不合理,具体为输入时出现连续的相同请求,例如<3><3><3>或者<5,DOWN><5,DOWN>,处理方法:程序自动忽略相同的多余输入,继续执行,例如<3><3><3>过滤为<3>
注意:本次作业类设计必须符合如上要求(包含但不限于乘客请求类、电梯类、请求队列类及控制类,其中控制类专门负责电梯调度过程),凡是不符合类设计要求此题不得分,另外,PTA得分代码界定为第一次提交的最高分代码(因此千万不要把第一次电梯程序提交到本次题目中测试)。
输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。
电梯内乘客请求格式:<楼层数>
电梯外乘客请求格式:<乘客所在楼层数,乘梯方向>,其中,乘梯方向用UP代表上行,用DOWN代表下行(UP、DOWN必须大写)。
当输入“end”时代表输入结束(end不区分大小写)。
输出格式:
模拟电梯的运行过程,输出方式如下:
运行到某一楼层(不需要停留开门),输出一行文本:
Current Floor: 楼层数 Direction: 方向
运行到某一楼层(需要停留开门)输出两行文本:
Open Door # Floor 楼层数
Close Door
输入样例1:
在这里给出一组输入。例如:
1
20
❤️,UP>
<5>
<6,DOWN>
<7>
<3>
end
输出样例1:
在这里给出相应的输出。例如:
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
输入样例2:
在这里给出一组输入。例如:
1
20
❤️,UP>
❤️,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
(2)分析
<1>知识点
单一职责原则(SRP):深入理解并应用单一职责原则,将电梯调度程序的功能拆分为多个类,每个类承担单一明确的职责,提高代码的可维护性和可扩展性。
类的设计与协作:设计电梯类、乘客请求类、队列类以及控制类,明确各类型的属性和方法,并实现它们之间的协作关系,以完成电梯调度功能。
异常处理:学会处理无效请求,如楼层数超出范围或连续相同请求,保证程序的健壮性。
<2>难度:较难。不仅要求实现电梯调度功能,还需遵循特定设计原则进行类的设计,对面向对象设计原则的理解和应用能力要求较高,同时要处理更复杂的输入情况。
<3>设计方法与类
电梯类:负责管理电梯的状态和基本操作,如移动、开关门等。
乘客请求类:用于封装乘客的请求信息,包括请求楼层和方向等。
队列类:管理乘客请求队列,实现请求的添加、删除等操作。
控制类:协调其他类的工作,根据请求和电梯状态决定电梯的运行方向和停靠楼层,实现电梯调度逻辑。
主程序类:负责读取用户输入,创建各类对象,并将请求传递给相应对象进行处理。
(3)
<1>代码规模相关
Lines:代码行数为 295 行,包含实际代码、空白行、注释行等所有行,反映文件的总体规模。
Statements:语句数是 163 条,代表实际执行操作的代码语句数量,不包含注释和空白行,体现代码实际功能指令数量。
<2>代码结构相关
Percent Branch Statements:分支语句所占百分比为 20.2% ,表示代码中if、switch等分支逻辑语句在总语句数中的占比,比例越高说明代码逻辑分支越复杂。
Method Call Statements:方法调用语句数为 77 条,统计代码中调用其他方法的语句数量,反映代码中方法间的调用频繁程度。
Percent Lines with Comments:含注释行的百分比是 4.1% ,即注释行在总行数中的占比,该比例较低,可能影响代码可读性。
Classes and Interfaces:类和接口数量为 2 个,体现代码的模块化程度,数量较少说明代码的封装和抽象层次可能相对简单。
Methods per Class:平均每个类的方法数为 15.00 ,通过方法总数除以类的数量得出,表明每个类承担的功能相对较多。
Average Statements per Method:每个方法平均语句数是 5.23 ,由语句总数除以方法总数得到,反映方法的平均规模大小。
Line Number of Most Complex Method:最复杂方法所在行号为 232 行 ,指出代码中复杂度最高的方法在文件中的位置。
Name of Most Complex Method:最复杂方法名称是Main.main() ,明确复杂度最高的方法所属类及方法名。
Maximum Complexity:最大复杂度为 15* ,用于衡量方法复杂程度,值越大方法逻辑越复杂,可能与复杂度计算方法有关。
Line Number of Deepest Block:最深代码块所在行号为 261 行 ,表示代码中嵌套层次最深的代码块所在位置。
Maximum Block Depth:最大代码块深度为 8 ,即代码中嵌套结构(如循环、条件语句嵌套 )的最大层数,反映代码结构复杂程度。
Average Block Depth:平均代码块深度是 1.91 ,通过对所有代码块深度求平均得到,体现代码整体的嵌套复杂程度。
Average Complexity:平均复杂度为 15.00 ,对文件中所有方法复杂度求平均,用于体现代码总体的复杂程度。
<3>复杂方法列表
仅列出Main.main()方法,其复杂度为 15* ,有 42 条语句,最大深度为 8,方法调用数为 22 。说明该方法复杂度较高,代码量和嵌套层次相对较多,方法间调用也较频繁。
<4>代码块深度统计
按代码块深度分类统计语句数量:深度为 0 的代码块有 50 条语句,深度为 1 的有 45 条等。通过该统计可直观了解不同嵌套深度代码块在代码中的分布情况,深度越大的代码块占比越高,代码结构越复杂。
3.第三次大作业
(1)题目
对之前电梯调度程序再次进行迭代性设计,加入乘客类(Passenger),取消乘客请求类,类设计要求遵循单一职责原则(SRP),要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类,具体设计可参考如下类图。
电梯运行规则与前阶段相同,但有如下变动情况:
乘客请求输入变动情况:外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层,请求目的楼层>
对于外部请求,当电梯处理该请求之后(该请求出队),要将<请求源楼层,请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾)
注意:本次作业类设计必须符合如上要求(包含但不限于设计电梯类、乘客类、队列类以及控制类),凡是不符合类设计要求此题不得分,另外,PTA得分代码界定为第一次提交的最高分代码(因此千万不要把第一次及第二次电梯程序提交到本次题目中测试)。
输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。
电梯内乘客请求格式:<楼层数>
电梯外乘客请求格式:<请求源楼层,请求目的楼层>,其中,请求源楼层表示乘客发起请求所在的楼层,请求目的楼层表示乘客想要到达的楼层。
当输入“end”时代表输入结束(end不区分大小写)。
输出格式:
模拟电梯的运行过程,输出方式如下:
运行到某一楼层(不需要停留开门),输出一行文本:
Current Floor: 楼层数 Direction: 方向
运行到某一楼层(需要停留开门)输出两行文本:
Open Door # Floor 楼层数
Close Door
输入样例1:
在这里给出一组输入。例如:
1
20
<5,4>
<5>
<7>
end
输出样例1:
在这里给出相应的输出。例如:
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
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Open Door # Floor 5
Close Door
Current Floor: 4 Direction: DOWN
Open Door # Floor 4
Close Door
输入样例2:
在这里给出一组输入。例如:
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
(2)分析
<1>知识点
单一职责原则深化:在遵循单一职责原则的基础上,进一步优化类的设计,处理更复杂的业务逻辑,确保每个类的职责清晰单一。
类的设计变更与扩展:引入乘客类并取消乘客请求类,重新设计请求处理逻辑,理解类的设计变更对整个程序的影响,以及如何通过类的扩展实现新的功能需求。
请求处理逻辑变化:掌握外部请求输入格式的变化及处理方式,将处理后的外部请求目的楼层加入内部队列,实现更符合实际场景的电梯调度逻辑。
<2>难度:较难。在题目二的基础上,对请求处理逻辑进行了较大调整,需要重新梳理类之间的关系和交互,增加了新的类和复杂的业务规则,对编程能力和问题解决能力要求更高。
<3>设计方法与类
电梯类:与题目二类似,但需要适应新的请求处理逻辑,如处理外部请求出队后将目的楼层加入内部队列的操作。
乘客类:封装乘客的请求信息,包括源楼层和目的楼层,以及获取和设置这些信息的方法。
队列类:管理内部和外部乘客请求队列,根据新的需求调整请求的添加、删除等操作逻辑。
控制类:协调各类型的工作,根据新的请求处理逻辑决定电梯的运行方向和停靠楼层,实现电梯调度。
主程序类:负责读取用户输入,创建各类对象,并将请求传递给相应对象进行处理,同时处理输入格式的变化。
(3)
<1>代码规模相关
Lines:代码行数,共计 279 行,指文件中所有代码行的总数,包括空白行、注释行和实际代码语句行。
Statements:语句数,有 176 条,代表文件中实际执行操作的代码语句数量,不包含注释和空白行。
<2>代码结构相关
Percent Branch Statements:分支语句所占百分比,为 21.0% ,反映代码中 if、switch 等具有分支逻辑的语句在总语句数中的占比,该比例可体现代码逻辑的复杂程度。
Method Call Statements:方法调用语句数,为 96 条,统计文件中调用其他方法的语句数量,用于衡量代码中方法之间的调用频繁程度。
Percent Lines with Comments:含注释行的百分比,是 1.1% ,表示文件中注释行在总行数中的占比,体现代码注释的丰富程度,该比例较低可能影响代码的可读性。
Classes and Interfaces:类和接口数量,有 7 个,指文件中定义的类和接口的总数,反映代码的模块化程度。
Methods per Class:平均每个类的方法数,为 4.57 ,通过文件中方法总数除以类的数量得出,用于评估每个类的功能丰富度。
Average Statements per Method:每个方法平均语句数,是 3.88 ,由语句总数除以方法总数得到,体现方法的平均规模大小。
Line Number of Most Complex Method:最复杂方法所在行号,在 168 行 ,表示文件中复杂度最高的方法在代码中的具体位置。
Name of Most Complex Method:最复杂方法名称,是 Controller.move () ,明确复杂度最高的方法所属类及方法名。
Maximum Complexity:最大复杂度,为 11* ,用于衡量方法复杂程度,值越大表示方法的逻辑越复杂,* 可能表示复杂度计算方法的某种标记或说明。
Line Number of Deepest Block:最深代码块所在行号,在 157 行 ,指出代码中嵌套层次最深的代码块所在的行。
Maximum Block Depth:最大代码块深度,为 5 ,表示代码中嵌套结构(如循环、条件语句嵌套 )的最大层数,可衡量代码结构的复杂程度。
Average Block Depth:平均代码块深度,是 2.16 ,反映代码整体的嵌套复杂程度,通过对所有代码块深度求平均得到。
Average Complexity:平均复杂度,为 2.78* ,对文件中所有方法复杂度求平均,用于体现代码总体的复杂程度,* 同样可能与复杂度计算方法有关。
<3>复杂方法列表
列出了不同类中较复杂的方法,以及其复杂度(Complexity)、语句数(Statements)、最大深度(Max Depth)和方法调用数(Calls) 。例如 Controller.move () 方法,复杂度为 11* ,有 22 条语句,最大深度为 4,方法调用数为 19 。这些信息有助于深入了解每个方法的复杂度、规模和调用情况,复杂度越高、语句数越多、最大深度越大以及方法调用数越多,方法的实现可能越复杂。
<4>代码块深度统计
按代码块深度(Block Depth )分类,统计对应深度下的语句数量(Statements) 。如深度为 0 的代码块有 9 条语句,深度为 1 的有 43 条语句等。通过这种统计,可以直观地了解不同嵌套深度的代码块在代码中的分布情况,深度越大的代码块占比越高,代码结构可能越复杂。
(4)思考过程
输入测试样例一的时候得到的是正确的结果
但是输入测试样例二的时候输出结果为空,猜想可能是由运行超时导致的,
踩坑心得
1.在写代码的时候没有衔接得当,使得在第一次运行案例的输出中,到达乘客所需要的最高层以后而不往下到达预计最底层,使得输出不正确
2.运行超时导致代码只能对第一个案例分析成功而第二个案例的输出结果为空
3.输出时忘记输出电梯再第一行的运动状态。
4.结尾多输出了一个空行,通过判断语句取消了这个空行。
建议
1.建议详细设计测试点,细分得分点。
2.自己写题前需要先设计类图,先构建完整骨架再填充完成代码。
3.尽量减少if-else语句的使用,导致程序语句累赘。
4.希望题目可以多给出几个输入输出的案例,方便理解和测试。
5.对于运行超时的问题,尽量减少重复语句的使用,优化数据结构。
6.提升自我java能力,加快敲代码的速度,提高熟练度。
总结
1在Java学习里,这三道电梯调度程序题作用很大。
2题目一让我掌握基础的类设计、数据结构使用和逻辑判断,能实现基本功能和处理异常请求。
3题目二遵循单一职责原则重新设计,我学会了拆分职责,提升代码的质量和可维护性,还处理了特殊请求情况。
4题目三引入新类和改变请求处理逻辑,锻炼了我应对需求变化的能力。三道题由浅入深,帮我积累了知识和经验,对Java编程理解更深刻。
5耐心写题,在多次试错中不断总结经验。
6空想不如实践,动手能力非常重要。