第三次Blog作业

Java 面向对象程序设计课程总结性 Blog
前言：课程学习概况
回顾整个 Java 面向对象课程的学习历程，从基础语法到复杂系统设计，从单类实现到多层架构搭建，课程内容呈现出循序渐进的难度梯度。PTA 作业以电梯调度系统和航空货运管理系统为载体，通过三次迭代设计逐步深化面向对象思想的应用，每次作业都需要经历需求分析、类设计、代码实现、复杂度优化及测试调试的完整流程，单份作业代码量平均达到 200 行以上，加上实验报告和 Blog 作业，整体工作量较为饱满。

线上课程通过理论讲解构建知识框架，线下实验则侧重实战应用，特别是复杂度分析工具的使用（如循环复杂度 v (G) 的计算）和代码重构训练，让我深刻体会到理论与实践结合的重要性。课程难点主要集中在复杂业务逻辑的面向对象建模（如电梯调度中的状态管理）、设计模式的灵活应用以及系统性能优化等方面，这些挑战也正是提升编程能力的关键所在。

面向对象技术总结
核心技术掌握情况
封装：数据与行为的边界守护
• 实践应用：在电梯调度系统中，将电梯状态（当前楼层、运行方向）和请求队列封装在 Elevator 类中，通过 get/set 方法控制访问，避免外部直接修改导致的逻辑混乱；航空货运系统中，Customer 类封装客户信息，确保数据一致性。
• 认知提升：封装不仅是 "私有化属性 + 公共方法"，更重要的是将相关行为（如货物计费计算）与数据绑定，形成高内聚的模块。
• 不足：初期设计时存在 "数据贫血类"（仅有 get/set 方法），未充分挖掘类的行为封装，如 Good 类早期未封装费率计算逻辑。

继承与多态：代码复用与行为扩展
• 实战场景：航空货运系统中，将 Good 类抽象为父类，派生出 NormalGood、ExpediteGood、DangerousGood 子类，通过重写 getRate () 方法实现不同货物的费率策略；电梯调度中虽未直接使用继承，但状态模式的思想隐含其中（如电梯运行状态的切换）。
• 关键认知：多态的本质是 "接口统一，实现各异"，通过父类引用指向子类对象，使代码具备扩展性（如新增货物类型时无需修改订单类）。
• 待改进：继承层次设计不够深入，部分场景过度使用组合而非继承（如电梯请求队列管理），未充分发挥继承的复用优势。

抽象类与接口：契约与规范
• 应用案例：第二单元将 Good 设计为抽象类，强制子类实现 calculateFare () 方法，确保所有货物类型遵循统一的计费接口；实验中尝试用接口定义电梯调度策略，为不同算法（如 SCAN、LOOK）提供统一入口。
• 理解深化：抽象类侧重代码复用（提供部分实现），接口侧重行为规范（纯定义），两者结合可构建灵活的系统架构。
• 薄弱点：接口隔离原则应用不足，部分接口包含过多无关方法，如 Flight 类接口曾混入与载重无关的属性操作。

集合框架：数据结构的 Java 实现
• 高频使用：电梯调度中使用 LinkedList 存储请求队列，航空货运中用 ArrayList 动态管理货物列表，充分利用 List 的有序性和可变性；Map 用于存储客户折扣规则（如类型 - 折扣率映射）。
• 性能体会：ArrayList 的随机访问效率高于 LinkedList，但在频繁插入删除场景下 LinkedList 更优，如电梯请求的动态增减场景。
• 未掌握部分：Queue、Set 等集合的高级应用较少，如 PriorityQueue 在电梯请求优先级排序中的潜在应用未充分挖掘。
异常处理：程序健壮性的保障
• 实践经历：第二单元处理输入异常时，通过 try-catch 捕获数值转换错误，避免程序崩溃；电梯调度中添加楼层有效性验证（如低于最低楼层的请求忽略）。
• 认知误区：初期过度依赖 try-catch 包裹整段代码，未做到 "哪里可能出错就在哪里处理"，导致异常栈难以追踪。
• 改进方向：未深入学习自定义异常类（如 OrderException），无法精准区分业务异常和系统异常。
JavaFX：GUI 编程的初探
• 接触情况：课程中未系统涉及 JavaFX，仅在实验拓展部分尝试用 Stage 和 Scene 实现简单的电梯状态可视化，但布局管理（如 BorderPane、GridPane）和事件处理（如按钮点击监听）掌握有限。
• 不足：缺乏复杂界面设计经验，如数据与界面的双向绑定（Property）、FXML 文件的使用等核心功能未深入学习。

技术体系构建反思
通过课程学习，已建立面向对象设计的基本思维框架：从需求中抽象类（如电梯→Elevator 类），定义类间关系（订单→包含货物），通过封装隐藏细节，用多态应对变化。但对设计模式的应用仍停留在 "事后重构" 阶段，如工厂模式（创建不同货物对象）、策略模式（电梯调度算法）未能在初期设计中主动应用，导致代码扩展性不足。

采坑心得：从错误中成长
代码设计与实现陷阱
• 复杂度失控：第一次电梯作业中，handleBothRequests 方法的循环复杂度高达 11，多层 if-else 嵌套导致逻辑混乱。解决方法：将方向处理逻辑拆分为 handleUpDirection、handleDownDirection 等私有方法，使单个方法复杂度控制在 5 以内。
• 状态管理漏洞：第二次电梯作业中，处理完请求后错误地将电梯方向设为 IDLE，导致优先级判断失误。根本原因：未理解 "同一方向请求处理完毕才改变方向" 的业务规则，通过添加方向状态检查机制修复。
• 输入处理陷阱：航空货运作业中，读取 int 后直接调用 nextLine () 导致空字符串问题。原理：nextInt () 不消耗换行符，nextLine () 读取剩余换行符。解决：每次读取数值后手动调用 scanner.nextLine () 消耗换行符。

测试与调试误区
• 边界条件遗漏：电梯调度测试时未考虑 "请求楼层等于当前楼层" 的情况，导致开门逻辑错误；货物计费未测试重量为 0 的边界，通过补充 PTA 测试用例发现并修复。
• 性能优化忽视：互测中发现处理大量请求时速度缓慢，原因是遍历请求队列使用低效的线性查找。改进：将 LinkedList 替换为 ArrayList，并引入索引查找优化。
• 日志输出冗余：电梯多次到达同一楼层时重复输出方向，通过添加 "是否连续到达同一楼层" 的标志位优化输出逻辑。
设计模式应用盲区
• 初期忽视设计模式：第一单元完全基于功能实现，未考虑模式应用，导致代码难以扩展；第二单元尝试使用工厂模式创建货物对象，但实现不够规范（如硬编码子类名称）。
• 接口隔离不足：Order 类接口包含过多与输出无关的方法，违背接口隔离原则，通过拆分为 OrderService 和 OrderPrinter 接口优化。
• 依赖倒置原则违反：Controller 类直接依赖具体的 Elevator 实现类，而非接口，导致难以替换调度策略，后续通过引入 ElevatorService 接口解耦。

改进建议与课程总结
教学与学习优化建议

课程内容设计
• 强化设计模式实践：建议在 PTA 作业中明确引导设计模式应用，如第一单元电梯调度可引入状态模式（电梯状态切换），第二单元货物计费可引入策略模式（不同费率策略），并提供模式应用示例代码。
• 增加 JavaFX 实战：可在实验中加入简单的 GUI 模块，如电梯运行可视化、货运订单界面设计，配套讲解 FXML、事件驱动编程等核心概念，提升综合实践能力。
• 复杂度分析前置：在第一次 PTA 作业中即引入 Cyclomatic Complexity 等指标，并要求方法复杂度不超过 7，培养代码质量意识。

作业与实验优化
• 分阶段验收作业：对于复杂的迭代作业（如电梯调度），可设置中间验收节点（如类图设计、核心方法伪代码），及时纠正设计偏差，避免后期大规模重构。
• 实验增加代码审查环节：在实验报告中要求对同学代码进行复杂度分析和设计模式点评，通过 peer review 强化面向对象设计原则的理解。
• 补充设计模式案例库：提供不同场景下的设计模式应用案例（如电梯调度→观察者模式通知请求，货运系统→工厂模式创建货物），供学生参考学习。

学习方法建议
• 测试驱动开发（TDD）：在编写代码前先设计测试用例，如电梯调度先定义 "同方向请求优先" 的测试场景，再实现功能，减少逻辑漏洞。
• 代码重构常态化：每次作业完成后进行重构优化，如将高复杂度方法拆分、提取公共逻辑为工具类，逐步培养重构意识。
• 设计模式刻意练习：每周分析一个开源项目的设计模式（如 JDK 集合框架中的迭代器模式），撰写分析笔记，提升模式识别能力。

课程总结
这门课程不仅教会了 Java 面向对象的语法和技术，更重要的是培养了 "问题建模→系统设计→代码实现→测试优化" 的完整软件开发思维。从电梯调度的状态管理到航空货运的多态应用，每一次作业都是对面向对象思想的深度实践，每一个 bug 都是理解深化的契机。尽管在设计模式应用、复杂系统架构等方面仍有不足，但已建立起持续学习的意识 —— 面向对象不是编程语言的特性，而是解决复杂问题的思维方式，需要在后续项目中不断锤炼。

感谢课程带来的挑战与成长，未来将继续深耕设计模式和架构设计，让代码不仅能 "运行"，更能 "演进"。