PTA大作业总结Blog

PTA大作业一：
1.前言：
大作业一涉及五道题目，分别是
（1）身份证校验位：核心是加权求和与取模运算的校验算法。
（2）求解一元二次方程（类设计）：核心是使用类（Class）将数据（系数）和操作（求解方法）封装在一起。
（3）验证码校验：核心是使用正则表达式定义合法字符和长度规则进行匹配。
（4）QQ号校验：核心是使用正则表达式匹配“非0开头的数字序列”这一特定模式。
（5）单部电梯调度：核心是队列（Queue）数据结构与getnextFloor算法的结合运用。
其中前四道题目中规中矩，不算简单。最最最让人头痛的是电梯调度这一道题目，实在是难，整整花了我好久哦。废话已经多说，就不多说了，下面是设计与分析
2.设计与分析：
SourceMonitor报表分析

根据报表可以得出：
方法复杂度过高
证据：Average Statements per Method: 9.08（每个方法平均9.08条语句）
分析：健康的方法通常不超过10-15行。平均值已接近上限，说明存在"上帝方法"。
改进：重点重构nextFloor()和moveTo()方法。
注释严重不足
证据：Percent Lines with Comments: 12.2%（注释行占比仅12.2%）
分析：低于业界推荐的20-30%标准，影响代码可读性和可维护性。
改进：为所有公开方法添加注释。
分支语句占比较高
证据：Percent Branch Statements: 28.3%（分支语句占比28.3%）
分析：表明代码中存在大量if-else逻辑，特别是调度算法部分。
类图分析：

从类图发现的设计问题：
Elevator 类职责过重
问题：Elevator 类同时负责移动、调度、输入解析、队列管理等，违反单一职责原则。
改进：引入调度器专门负责决策。
请求处理设计不合理
问题：内部请求（单一整数）和外部请求（楼层+方向）使用不同处理方式，但继承关系利用不足。
改进：统一请求处理机制。
3.踩坑心得：
此次大作业我只觉得自己踩的坑还是有点多的，其中有正则表达式不怎么熟悉，还有对电梯调度逻辑不怎么理解，然后考虑到输入格式问题，输出空行问题，结果在这里面都不怎么管！
4.改进建议：
PTA大作业一里电梯类里承担了太多的责任，而且逻辑不是特别清楚，不容易后面去理解，可以将代码的各个功能再细化一点，比如代码里有寻找下一个要去的楼层的这么一个类，它需要同时考虑内部按钮的请求（乘客要去的目标楼层）和外部按钮的请求（乘客在楼层等候电梯）。这里可以使用
结构重构，将这里复杂的条件判断分解为多个致力于单一职责的小方法，比如
分离状态处理：为电梯的三种状态（空闲、上行、下行）创建独立的处理方法
提取辅助方法：将“是否在路线上”、“是否更近”等判断逻辑提取为独立方法
清晰的主流程：主方法只负责协调，具体逻辑由专门方法处理
5.总结：
本次大作业全面考察了面向对象编程、数据结构、算法设计和字符串处理等多个方面的编程能力。通过完成这些题目，特别是具有挑战性的电梯调度问题，加深了对以下核心概念的理解：
面向对象设计原则：单一职责、开放封闭等原则的实际应用
算法设计思维：如何将复杂问题分解为可管理的子问题
代码质量意识：注释、可读性、可维护性的重要性
调试与测试：系统化的错误定位和修复方法
最大的收获是认识到良好的架构设计对复杂系统的重要性。在今后的编程实践中，将更加注重代码的结构设计和质量管控，避免出现"上帝类"和"上帝方法"等问题。
此次经历也暴露出在正则表达式和复杂算法实现方面的不足，需要在后续学习中重点加强，以及自己理解电梯运行逻辑有问题。

PTA大作业二：
1.前言：
大作业二涉及三道题目，分别是：
NCHU_点与线（类设计）：设计类表示基本的几何元素——点（point）和线(line),实现计算两点之间计算距离的操作，需要运用封装，抽象，类的定义与实现等。
NCHU_汽车风挡玻璃雨刷问题（类设计）:设计三个类分别表示控制杆、刻度盘，以及雨刷速度，雨刷的摆动速度由控制杆、刻度盘两种元件决定。
NCHU_单部电梯调度程序（类设计）:解决电梯类职责过多的问题，类设计要求遵循单一职责原则，此次PTA大作业目的就是为了解决之前大作业Elevator类的问题，以及添加了输入检查的问题。
2.设计与分析：
SourceMonitor报表分析：

增加注释：带注释的行仅占4.6%，建议在关键逻辑、方法、类上添加注释，提升可读性和可维护性。
类图分析：

主要有以下问题：
①Main类职责过重，拆分职责
class InputParser /* 专门处理输入解析 /
class RequestValidator / 验证请求合法性 /
class Application / 协调各个组件 */
②Controller类调度算法复杂，这里有个聪明的家伙叫我使用使用策略模式将不同调度算法分离。
③输入验证和错误处理不够完善。
3.踩坑心得：
这里踩过的坑，主要是在class Controller里没有使用正确的处理逻辑，即processRequests()，这里正确的处理逻辑应该是当内外请求同时存在时，执行复杂的多条件优先级判断。第一优先级考虑外部请求方向与电梯当前运行方向的一致性，并结合内部请求的方向因素；第二优先级比较内外请求的相对距离，采用"就近服务"原则；最后回退到基于方向匹配的简单判断。这种设计体现了电梯调度中"同向优先"和"距离优先"的混合策略。
4.改进建议：
内部请求和外部请求分离存储，增加了调度复杂度，缺乏对异常情况的处理机制。
5.总结：
电梯调度系统实现了基本功能框架，但在核心调度算法和系统架构方面存在明显改进空间。
PTA大作业三：
1.前言：
此次大作业包括：
NCHU_销售步枪问题：这里主要是解决利率的问题。
NCHU_蒙特卡罗方法求圆周率： 这里主要是阅读文档和使用随机数解决求圆周率问题。
NCHU_单部电梯调度程序（类设计-迭代）：这里主要是对之前大作业的迭代，乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
2.设计与分析：
设计：该电梯调度系统采用分层架构设计，以Controller类为核心调度器，通过组合模式整合Elevator（电梯状态管理）、RequestQueue（请求队列管理）和Passenger（乘客请求封装）三个核心组件。系统运行时，Main类作为入口接收用户输入并初始化各模块，Controller通过优先级算法协调处理内部楼层请求和外部乘客请求：当电梯接收到乘客请求时，先移动到乘客所在楼层并开门，然后将目的地转为内部请求；调度逻辑基于电梯当前方向、请求距离和类型进行动态决策，确保电梯按合理顺序响应各类请求，最终通过状态机模式控制电梯的移动、停止和开关门等基本操作，形成一个完整的请求处理闭环。
SourceMonitor报表分析：

核心逻辑集中在Controller和Main类的高复杂度方法中。项目结构基本清晰，但存在方法过重、类职责不单一、注释不足等问题。
类图分析：

类被划分为 主程序（Main）、控制逻辑（Controller）、请求管理（RequestQueue）、电梯核心组件（Elevator、Passenger、Direction、State）​ 四大模块，面向对象特性（封装、枚举、集合）的应用，覆盖电梯的核心行为：上下楼（moveUp()/moveDown()）、开关门（openDoor()）、状态切换（setState()）、请求处理（processRequests()处理内外请求）。

3.踩坑心得：
主要在添加乘客请求时，对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾） ，这里处理要严谨一点，然后处理逻辑与之前的别无二致。
4.改进建议：
单电梯限制，扩展性不足（多电梯场景）
当前仅支持单电梯，若需扩展为多电梯系统，需大幅修改 Controller（如维护 Elevator列表、实现请求分配算法），现有结构的扩展性有限。
请求处理逻辑简单，缺乏灵活性
RequestQueue使用 LinkedList（先进先出），无法支持优先级调度（如紧急请求优先、近楼层请求优先）。
请求处理方法（如 processRequests()）的逻辑未明确（如如何协调内外请求、如何选择电梯），可能导致逻辑混乱。
异常处理缺失
未考虑边界情况（如电梯到达最大/最小楼层、请求非法楼层、多请求冲突），现有方法（如 Elevator的 moveUp()）缺乏异常处理逻辑，可能导致程序崩溃。
5.总结：
基于Java的单电梯调度系统，通过面向对象设计实现了电梯的基本运行控制，系统包含电梯状态管理（Elevator类）、乘客请求处理（Passenger类）、请求队列管理（RequestQueue类）和核心调度逻辑（Controller类），其中Main类作为程序入口负责初始化系统和处理用户输入。该系统能够处理内部楼层请求和外部乘客请求（包含起点和终点），并采用简单的优先级调度算法来决定请求处理顺序，但存在核心方法processRequests()复杂度较高（复杂度14）、代码注释率偏低（5.3%）以及部分类职责不够单一等可优化空间，整体架构清晰但需要在代码质量和算法效率方面进一步改进。