面向对象课程设计总结性Blog

一、前言
本学期的面向对象课程，通过航空管理系统迭代与电梯调度程序设计两大核心项目，构建起理论与实践深度融合的学习体系。从作业类型看，Blog 作业需梳理知识、沉淀思考，锻炼总结表达；PTA 作业聚焦语法与算法，巩固基础；实验环节（航空、电梯项目）则以完整工程实践，推动知识落地。线上课程提供灵活学习资源，线下课程侧重互动讲解与难点剖析。整体工作量饱满，航空管理系统迭代涉及类重构、设计原则应用，电梯调度则聚焦复杂逻辑处理，难度阶梯式上升，持续挑战认知边界，逼着我从 “代码实现者” 向 “系统设计者” 转变 。
二、面向对象技术总结
（一）封装：从业务逻辑到状态管理
在航空管理系统中，最初支付类与配送类耦合，暴露内部逻辑。通过重构，将支付计算、配送费率等核心逻辑封装到对应类，仅对外提供简洁接口（如支付类的calculateFee方法，通过配送类引用获取费率，而非直接依赖内部实现）。这让我明白，封装是构建 “黑盒组件” 的关键 —— 隐藏复杂细节，保障系统稳定性。
电梯调度项目里，电梯状态（运行、停止、开关门）、乘客请求（内部 / 外部、上下行）的封装同样重要。比如Elevator类封装当前楼层、方向、请求队列，外部通过addRequest等方法交互，避免直接操作内部状态引发混乱。但复杂场景下，如何平衡封装颗粒度仍需探索，像电梯状态切换时，部分过渡逻辑（如 “停止后自动开门”）的封装，需兼顾灵活性与简洁性，目前在电梯项目中处理得不够优雅，还需优化。
（二）继承与多态：代码复用与场景适配
航空管理系统迭代中，支付模块是继承与多态的典型应用。抽象支付类Pay定义calculateFee抽象方法，AliPay、WePay等子类重写实现，主程序通过Pay父类引用调用，轻松扩展新支付方式。这验证了 “里氏替换原则”—— 子类无缝替代父类，提升系统扩展性。
电梯调度本可借继承优化（如不同电梯类型继承基类，重写调度逻辑），但因我对复杂逻辑拆分不足，未能充分落地。实际开发中，乘客请求的 “处理策略”（如优先响应内部请求、按方向顺路载客）可抽象为接口，不同策略类实现多态，这是后续改进方向。目前对多态在复杂业务流程中的串联应用，理解仍停留在 “语法层面”，需通过更多项目深化。
（三）抽象类与接口：架构设计的骨架
航空项目里，抽象支付类Pay定义公共行为（费用计算规范），子类实现具体逻辑，是抽象类 “部分实现、规范约束” 的体现；而货物类型、支付方式用枚举替代字符串，虽非传统接口，却起到 “行为契约” 作用（限定合法取值）。后续若扩展 “会员支付接口”，可更清晰分离职责 —— 接口定义支付行为，抽象类处理公共属性，增强架构弹性。
电梯调度中，请求处理、电梯运行的 “行为规范” 可通过接口强化。比如定义RequestHandler接口，规范请求入队、出队逻辑；ElevatorRunner接口约束电梯移动、状态变更行为。当前代码因缺乏接口分层，类间依赖较深，修改调度策略时牵一发而动全身，暴露对 “接口隔离原则” 应用不足的问题，需在重构中重点优化。
（四）集合框架：数据流转的 “管道”
航空管理系统用ArrayList存储货物、订单，HashMap处理客户信息映射，解决了数据动态管理需求。但初期因对集合遍历、增删操作不熟悉，出现 “ConcurrentModificationException”（遍历中修改集合），后通过迭代器或CopyOnWriteArrayList规避。这让我重视集合使用场景 ——ArrayList适合随机访问，LinkedList擅长频繁增删，需根据业务选工具。
电梯调度对集合依赖更重：用ArrayList维护内外请求队列，需实时排序、筛选（如按楼层顺序处理同方向请求）。但我在实现 “顺路载客” 逻辑时，因对Collections.sort自定义比较器不熟练，排序逻辑混乱，导致电梯乱跑楼层。后续需深入掌握集合工具类（如Comparator、Collections），让数据流转更高效。
（五）异常：系统鲁棒性的 “安全网”
航空项目初期，文件读写、支付计算未做异常处理，遇到非法输入（如负数楼层、无效支付方式）直接崩溃。通过添加try - catch捕获IOExcepiton、自定义BusinessException（如 “航班超载异常”），并在finally释放资源，系统稳定性显著提升。但异常分类仍显粗糙，需细化（如区分 “业务逻辑异常” 与 “技术异常”），方便定位问题。
电梯调度中，输入解析（正则匹配失败）、楼层越界（请求楼层超出电梯范围）等场景，同样需要异常守护。我曾因未处理 “无效请求输入”，导致程序因NumberFormatException崩溃，后通过正则严格校验输入，配合异常捕获提示用户重新输入，完善了鲁棒性。但异常处理的 “颗粒度” 仍需平衡 —— 过度捕获会掩盖真实问题，需精准识别关键风险点。
（六）JavaFX 与 GUI（航空项目涉及）
航空管理系统用 JavaFX 实现界面，初期因对布局（BorderPane、VBox）、事件绑定（按钮点击触发订单提交）不熟悉，界面与逻辑严重脱节。通过Scene Builder可视化设计，结合Controller类分离业务逻辑，逐步实现 “点击按钮→调用后台方法→更新界面状态” 的完整流程。但复杂交互（如订单列表实时刷新、动画效果）仍难驾驭，对JavaFX线程模型（Platform.runLater处理 UI 更新）理解不深，导致多线程场景下界面卡顿，这是 GUI 开发待突破的难点。
三、采坑心得：从 “卡壳” 到 “开窍” 的实战反思
（一）航空管理系统：设计思维的觉醒
耦合度 “泥潭”：最初支付与配送类紧耦合，修改费率逻辑需改动多处，如同 “牵一发动全身”。后通过抽象类引入依赖、分离职责，才挣脱耦合泥潭。这让我明白，设计初期要画好 UML 类图，明确类间关系，避免 “代码写完才发现结构歪了”。
扩展性 “困局”：未用枚举时，新增支付方式要改大量条件判断，如同 “给旧房子硬塞新家具”。引入枚举后，新增类型只需扩展枚举常量，系统瞬间灵活。这验证了 “开闭原则”—— 对扩展开放、对修改关闭，是应对需求变化的关键。
主类 “臃肿病”：航空项目初期，主类包揽输入、逻辑、输出，代码长达数百行，调试时如同 “在一团乱麻里找线头”。拆分辅助方法（如折扣计算、支付方式创建）后，主逻辑清晰，维护成本大降。从此深知 “单一职责原则” 不是口号，是代码可维护的底线。
（二）电梯调度程序：逻辑攻坚的血泪史
输入解析 “拦路虎”：第五次题目集因正则表达式知识空白，输入处理直接卡壳。补学正则后，用Pattern、Matcher提取楼层、方向，才打通数据流入的 “第一关”。这让我重视 “先补知识短板，再攻坚业务”—— 工具不会用，再简单的需求也做不出。
队列管理 “混乱局”：电梯内外请求队列的增删、排序、匹配逻辑复杂，初期因对ArrayList操作不熟悉，请求插队、漏处理频发，电梯要么 “瞎跑” 要么 “不动”。后通过封装队列操作（如addRequestWithOrder方法，按楼层和方向排序入队），才让请求流转有序。这体现 “数据结构 + 算法” 是解决复杂逻辑的基石，需扎实掌握。
状态切换 “连环错”：电梯开关门、移动、状态变更的时序逻辑（如 “停止后必须先开门，再处理请求”），因缺乏流程图梳理，代码写得 “前言不搭后语”，出现 “开关门后楼层重复输出”“未处理完请求就移动” 等问题。后通过画状态转移图，明确 “停止→开门→处理请求→关门→移动” 的流程，才理顺逻辑。这让我学会 “用可视化工具拆解复杂流程”，再转化为代码。
四、改进建议：让学习更高效的思考
（一）课程内容：强化 “项目 - 理论” 映射
航空与电梯项目可增加 “设计模式专项讲解”，比如航空支付模块对应 “策略模式”，电梯调度的请求处理可关联 “状态模式”，让抽象理论落地到真实代码。还可引入 “微重构挑战”—— 给初始 “Bad Smell” 代码（如耦合严重、职责混乱的版本），让学生分步优化，强化设计原则应用能力。
（二）作业设计：分层引导与复盘机制
作业可分 “基础实现→优化重构→扩展创新” 三阶。基础题保障功能完成，优化题要求用设计原则重构（如航空项目要求拆分主类、解耦模块），扩展题鼓励创新（如电梯调度新增 “智能调度策略”）。同时，增加 “作业复盘报告”，要求分析代码改进点、踩坑原因，深化学习反思。
（三）实验支持：工具与流程辅助
针对电梯调度这类复杂项目，提供 “逻辑流程图模板”“典型异常场景测试用例”（如 “连续多层请求”“跨方向请求”），帮助学生梳理思路、验证代码。在线上平台补充 “集合操作”“正则表达式”“JavaFX 调试” 等迷你教程，解决知识断点问题，避免因工具不会用卡壳。
（四）交流互动：构建 “学习共同体”
线下课程增设 “项目攻坚工作坊”，分组讨论航空 / 电梯项目的设计难点，老师实时答疑、分享设计思路。线上搭建 “代码诊所” 板块，学生上传待优化代码，师生共同诊断（如 “这个类是否违反单一职责？怎么拆？”），营造互助学习氛围，让 “死磕代码” 变为 “协同成长”。
五、总结
回顾这一路，从航空管理系统的 “设计原则觉醒”，到电梯调度程序的 “逻辑攻坚突破”，面向对象课程不仅教会我 Java 语法、设计模式，更让我掌握 “用工程化思维解决问题” 的能力 —— 拆解需求、设计架构、迭代优化、排查问题。
虽在电梯调度中留有遗憾（未完全通过测试），但每一次卡壳、每一回调试，都让我更懂 “编程是试错的艺术”。未来，我会带着 “设计为先、工具为翼、交流为桥” 的理念，深耕开源项目，参与技术竞赛，把课堂所学融入真实场景。
也期待课程继续迭代，用更贴近实战的项目、更细致的引导，帮助更多同学跨越 “语法” 到 “设计” 的鸿沟，真正掌握面向对象编程的精髓 —— 让代码不仅能 “跑起来”，更能 “优雅地跑下去”，用技术创造真正有价值的应用。