第三次Blog作业

第三次Blog作业

（1）前言：课程学习概要总结

整门面向对象程序设计课程以渐进式的学习路径贯穿始终，从基础语法到复杂系统设计，各教学环节环环相扣。PTA 作业从最初的简单类定义逐步过渡到电梯调度系统、航空货运管理系统等复杂项目，题量虽不算爆炸式增长，但每一次迭代都伴随着设计复杂度的提升，对初学者而言是从 "功能实现" 到 "架构设计" 的思维跨越。三次 Blog 作业则强制要求对知识体系进行梳理，促使我在实践后反思代码设计与逻辑漏洞。

实验环节与线上课程形成互补，线上课程通过理论讲解建立知识框架，线下实验则通过具体案例落地抽象概念。印象较深的是电梯系统实验中，单步调试追踪请求处理流程的过程，让我直观理解了多线程调度与队列操作的实际运行机制。但整体工作量分配上，PTA 作业的代码量与逻辑复杂度占据了主要精力，尤其在航空货运系统中，策略模式与接口设计的综合应用曾让我熬夜调试。

（2）面向对象技术总结

核心技术掌握情况

封装、继承与多态

• 封装：从最初将属性私有化并提供 get/set 方法，到后期在航空货运系统中通过CargoInfo类封装计费逻辑，逐渐理解封装不仅是数据保护，更是业务逻辑的模块化。例如CargoInfo类将毛重、体积重计算封装为独立方法，外部仅需调用getChargeWeight()即可获取计费重量。
• 继承：在电梯系统中尝试通过抽象类ElevatorStrategy定义调度策略基类，子类实现不同调度算法（如 FIFO、SCAN），但初期因过度设计导致代码冗余，后期通过重构聚焦于 "方向判断" 等核心差异点，体会到继承应服务于 "is-a" 关系而非为复用而复用。
• 多态：策略模式的应用是对多态的最佳实践，航空货运系统中RateStrategy接口定义getRate()方法，不同重量区间的策略类（如RateStrategy1-RateStrategy12）实现该方法，订单类通过多态调用不同策略计算费率，真正实现了 "同一接口，不同实现" 的设计思想。

抽象类与接口

• 抽象类在电梯系统中用于定义Elevator基类的核心方法（如move()、processRequest()），强制子类实现关键逻辑；接口则在货运系统中分离业务逻辑，如PaymentMethod接口隔离支付方式，WechatPayment与AlipayPayment实现类解耦支付逻辑与订单处理。
• 认知提升：接口更适合定义 "能力契约"（如 "可支付"），抽象类更适合封装 "部分实现的共同行为"（如电梯的基本移动逻辑），初期常混淆两者应用场景，导致代码架构混乱。

集合框架与异常处理

• 集合框架：电梯系统中LinkedList实现队列处理请求，ArrayList存储输入数据；货运系统用HashMap映射客户信息。重点掌握了Queue接口的offer()、poll()操作，以及Collections工具类的排序与查找方法，但对ConcurrentHashMap等并发集合的应用仍停留在理论层面。
• 异常处理：初期常忽略输入验证，导致NumberFormatException等运行时异常崩溃程序，后期在货运系统中添加了输入楼层范围校验、重量合法性检查，通过try-catch块捕获并处理异常，提升了代码鲁棒性，但对自定义异常类的应用仍显生疏。

JavaFX 与图形界面

• 实验中接触 JavaFX 实现简单界面，如电梯运行状态可视化，但仅完成基础布局（VBox、HBox）与按钮事件绑定，对FXML文件加载、数据绑定等高级特性掌握不足。布局管理（如AnchorPane的锚点设置）常导致界面元素错位，动画效果完全未涉及，这部分技术存在明显欠缺。

技术短板与待提升点

• 设计模式深度应用：虽了解策略模式、工厂模式的基本概念，但在复杂系统中难以主动识别可应用场景，如货运系统中订单生成未使用工厂模式，导致Order类与具体策略类耦合过紧。
• 多线程编程：电梯系统中未实现真正的多线程调度（如请求处理与电梯移动并行），仅停留在单线程模拟，对线程安全、同步锁（synchronized）、BlockingQueue等并发工具的应用缺乏实践。
• JavaFX 进阶：界面与业务逻辑未实现 MVC 分离，代码中充斥着setOnAction的匿名内部类，可维护性差，需系统学习 FXML 与Application生命周期管理。

（3）采坑心得与经验教训

设计层面的典型错误

• 类职责混乱：电梯系统初期将调度逻辑、请求处理、输入输出全部塞进Elevator类，导致代码超过 800 行，方法嵌套深度达 7 层，调试时如同 "迷宫"。后通过拆分为Controller（调度）、RequestQueue（请求管理）、ElevatorView（输出）等类，使单类代码量控制在 200 行以内。
• 过早优化与过度设计：货运系统初期为 "未来可能的需求" 添加大量扩展接口，但实际作业中并未用到，反而增加了开发复杂度。领悟到 "YAGNI（You Aren't Gonna Need It）" 原则，应优先实现当前需求，再根据反馈迭代。

代码实现的高频陷阱

• 队列操作误区：电梯系统第一次作业中，错误地在到达楼层时移除所有匹配请求（removeIf(f -> f == currentFloor)），未遵循 FIFO 原则，导致方向判断错误。正确做法是仅移除队首请求，通过poll()或remove(0)实现先进先出。
• 接口隔离失败：货运系统初期设计的CargoService接口包含 12 个费率计算方法，违背接口隔离原则，后期拆分为NormalCargoRate、DangerousCargoRate等细分接口，降低了类实现的复杂度。
• 字符串解析漏洞：输入验证仅用正则表达式匹配格式（如<\d+,UP>），但未校验楼层范围（如 1-20 层），导致非法输入（如 30 层）时程序异常。需结合try-catch与范围判断双重校验。

调试与测试的不足

• 依赖样例测试：初期认为通过 PTA 样例一即完成任务，未主动构造边界测试用例（如电梯初始楼层为 1，请求为 20 层的极端情况），直到作业截止后才发现方向切换逻辑遗漏。
• 单步调试缺失：航空货运系统中费率计算错误时，未使用 IDE 的单步跟踪功能查看RateStrategy的调用链，而是盲目修改代码，浪费大量时间。掌握断点→步入→变量监视的调试流程后，效率显著提升。

（4）改进建议与课程总结

对课程与教学的建议

• PTA 题目引导优化：电梯系统作业可分阶段提示设计方向，如第一次作业重点标注 "注意队列 FIFO 原则"，第二次作业提示 "考虑方向切换条件"，减少初学者因理解偏差导致的反复试错。
• 实验案例场景化：现有实验多为独立功能演示（如 JavaFX 按钮点击），建议增加综合案例（如 "学生管理系统" 从数据模型到界面的完整实现），强化各技术点的协同应用。
• JavaFX 教学深化：当前课程对 JavaFX 的讲解停留在基础控件，建议增加 FXML 文件使用、CSS 样式定制、界面与数据绑定等内容，配套 "电梯运行可视化" 等实战项目，提升工程实践能力。
• 设计模式专题强化：可在课程中期安排设计模式专题课，结合电梯 / 货运系统案例讲解策略模式、工厂模式的应用场景，提供重构前后的代码对比，帮助学生建立设计思维。

个人学习总结与未来方向

通过整门课程的学习，最大的收获是从 "面向过程" 到 "面向对象" 的思维转变：不再将程序视为线性执行的指令集合，而是将现实问题抽象为对象交互的系统。电梯系统教会我 "职责分离" 的重要性，货运系统让我体会 "接口抽象" 如何提升代码扩展性，每一次作业迭代都是对 "高内聚、低耦合" 原则的实践深化。

但也清晰认识到自身不足：设计模式应用停留在模仿阶段，多线程与并发编程缺乏实战，JavaFX 界面开发能力薄弱。未来计划通过以下方式提升：

• 阅读更多优秀源码，结合开源项目（如 JDK 集合框架源码）分析模式应用；
• 完成 "多线程电梯调度" 扩展项目，实践ThreadPoolExecutor、CountDownLatch等并发工具；
• 开发 "个人记账 APP" 练手 JavaFX，学习 MVC 架构与 FXML 进阶技巧。

面向对象编程不是终点，而是复杂系统开发的起点。这门课程埋下的思维种子，将在未来的项目实践中持续生长，指引我写出更优雅、更健壮的代码。