面向对象程序设计题目集 5 - 7：我的编程成长手记

面向对象程序设计题目集 5 - 7：我的编程成长手记
前言
回顾完成题目集 5 - 7 的过程，就像在攀登一座陡峭的山峰，每前进一步都充满挑战，但也收获了意想不到的风景。这三次作业围绕面向对象编程核心知识展开，从基础概念到复杂应用，层层递进，不仅检验了课堂学习成果，更让我体会到理论与实践结合的重要性。
题目集 5 是入门阶段的试炼。当时的题目主要聚焦类的基础设计，比如设计一个简单的几何图形类，要求实现计算面积、周长等功能。整个题目集大约包含 6 道题，难度对刚接触面向对象编程的我来说，像一场 “破冰之旅”。刚开始写代码时，经常混淆属性和方法的定义，甚至闹出把计算逻辑写在属性里的笑话。但通过反复修改和调试，逐渐掌握了类的封装特性，也理解了对象实例化的过程。
题目集 6 难度陡然提升，引入了继承、多态等进阶概念。记得有一道设计 “员工管理系统” 的题目，需要从抽象的员工类派生出全职员工、兼职员工等子类，并根据不同类型实现差异化的薪资计算方法。这次作业题量增加到 8 道，每道题都需要深入思考类之间的层次关系。为了理清思路，我开始尝试在草稿纸上手绘类图，用不同颜色的笔标注继承关系和方法重写，这个笨办法却让我真正理解了多态的本质。
题目集 7 堪称 “终极挑战”，重点考查综合应用能力和代码优化思维。单部电梯调度问题贯穿其中，要求考虑电梯运行策略、请求队列管理等复杂逻辑。面对 10 道综合性题目，我常常对着需求文档反复琢磨，甚至在宿舍楼道里模拟电梯运行场景来帮助理解。这个阶段的学习，让我深刻体会到编程不仅是写代码，更是解决实际问题的过程。
设计与分析
题目集 5：单部电梯调度程序的 “青涩尝试”
在题目集 5 中，我设计的电梯调度程序采用 “大而全” 的思路，将所有功能集中在一个 Elevator 类里。这个类包含了电梯的运行参数（如最大楼层、最小楼层）、当前状态（当前楼层、运行方向），以及乘客请求处理的全部逻辑。在实现电梯运行规则时，我在 run 方法里堆砌了大量 if - else 语句，试图通过条件判断来控制电梯的移动方向和停靠逻辑。
比如，在处理请求队列时，我采用最直观的遍历方式：先检查上行请求，再处理下行请求。虽然程序最终通过了基础测试用例，但代码结构非常混乱。用 SourceMonitor 工具分析后发现，run 方法的圈复杂度高达 18，远超合理范围，这意味着代码的可读性和维护性极差。当时的我并未意识到单一职责原则的重要性，为后续迭代埋下了隐患。

题目集 6：遵循设计原则的 “重构之路”
题目集 6 要求按照单一职责原则重新设计，这对我来说是一次思维转变。我将原有代码拆分为 PassengerRequest、RequestQueue、Elevator 和 ElevatorController 四个类。
PassengerRequest 类专门负责封装乘客请求信息，通过重写 equals 和 hashCode 方法，实现了请求去重功能。记得在调试这个类时，曾因为忽略对象比较的细节，导致相同请求无法被识别，最终通过断点调试逐行检查才解决问题。RequestQueue 类使用 LinkedHashSet 管理请求，既保证顺序又能自动过滤重复项，这个设计让我第一次体会到数据结构选择对程序效率的影响。
Elevator 类专注于电梯的物理操作，如楼层移动、开关门等；ElevatorController 则作为调度核心，协调各个类之间的工作。我用 PowerDesigner 绘制了类图（如下图），清晰展示类之间的关联关系。这次重构后，代码的可维护性大幅提升。例如，当需要添加新的请求类型时，只需在 PassengerRequest 类中扩展，而不影响其他模块。

题目集6电梯调度程序类图

image
题目集 7：业务逻辑深化的 “再升级”
题目集 7 的电梯调度程序引入乘客类和新的请求格式，要求将外部请求的目的楼层自动加入内部队列。这一改动看似简单，实际涉及多个类的联动修改。我首先在 Passenger 类中增加源楼层和目的楼层属性，然后修改 RequestQueue 类的存储结构，分别管理外部请求（LinkedHashSet）和内部请求（Queue）。
在 ElevatorController 类中，我重新设计了请求处理逻辑。handleRequestsAtCurrentFloor 方法成为关键，需要同时处理外部请求的转换和内部请求的移除。调试过程中，曾出现请求重复处理的问题，经过反复检查发现是队列操作顺序错误导致的。这次经历让我明白，复杂业务逻辑的实现需要严谨的思维和细致的测试。
采坑心得
逻辑漏洞：调试桌上的 “持久战”
在题目集 5 的电梯程序中，我曾遇到一个诡异的问题：电梯在某些楼层会重复停靠。为了定位问题，我在代码中插入大量打印语句，记录电梯运行状态和请求处理过程。经过整整一个下午的排查，才发现是在判断请求优先级时，没有正确处理内部请求和外部请求的关系。这次经历让我养成了编写测试用例的习惯，通过覆盖边界值和异常场景来预防逻辑错误。
在题目集 7 的迭代中，新的请求转换逻辑也带来不少麻烦。例如，当连续出现多个相同源楼层的外部请求时，程序会出现队列混乱。我通过绘制请求处理流程图（如下），梳理每个步骤的操作，最终发现是在请求移除时没有同步更新队列状态。这个问题的解决让我深刻体会到，复杂逻辑的实现需要可视化工具的辅助。

类设计缺陷：牵一发而动全身的 “教训”
题目集 5 的单一类设计在后续维护时暴露出严重问题。当需要添加 “电梯负载监控” 功能时，我发现代码修改无从下手，一个小功能的添加导致多个模块出现异常。这让我深刻认识到设计原则的重要性。在题目集 6 的重构中，我虽然遵循了单一职责原则，但在类职责划分上仍存在模糊地带。例如，ElevatorController 类承担了过多的请求筛选逻辑，导致代码耦合度偏高。后来通过代码评审和同学讨论，将部分逻辑转移到 RequestQueue 类，才使结构更加清晰。
性能瓶颈：大数据测试下的 “狼狈时刻”
在题目集 7 的压力测试中，当模拟 1000 个乘客请求时，程序响应时间长达数十秒。通过分析发现，请求队列遍历的时间复杂度较高，尤其是在判断是否有同方向请求时，需要多次遍历集合。我尝试将外部请求队列改为 TreeSet，利用其排序特性减少遍历次数，性能提升显著。这个优化过程让我意识到，算法和数据结构的选择对程序效率有着决定性影响。
改进建议
代码结构优化
目前的代码虽然已经模块化，但仍有优化空间。可以进一步应用设计模式，例如使用策略模式封装不同的电梯运行策略（如高峰模式、平峰模式），这样在切换策略时只需修改配置，而无需修改核心代码。同时，应加强代码的分层设计，将业务逻辑、数据处理和界面展示分离，提高代码的可扩展性。
功能扩展方向
未来可以考虑为电梯调度程序增加更多实用功能。比如实现多电梯协同调度，通过算法优化不同电梯之间的任务分配；添加预约系统，支持用户提前指定乘坐时间和目的地；集成数据分析功能，根据历史请求数据预测高峰时段，提前调整运行策略。这些功能的实现将使程序更贴近实际应用场景。
性能提升策略
在性能优化方面，可以引入缓存机制减少重复计算，例如缓存最近处理的请求结果。对于多线程场景，合理使用锁机制和线程池技术，提高程序的并发处理能力。此外，定期进行代码审查和性能测试，及时发现并解决潜在的性能问题。
总结
完成题目集 5 - 7 的过程，是不断犯错、学习和成长的过程。从最初对面向对象概念的懵懂，到能够独立设计复杂系统，我不仅掌握了类设计、继承、多态等核心知识，更重要的是培养了解决问题的思维方式。每次遇到难题时，从最初的焦虑到逐渐冷静分析，再到最终找到解决方案，这种思维转变比单纯的代码能力提升更有价值。
当然，我也清楚认识到自己的不足。在算法设计方面，我还缺乏经验，面对复杂问题时常常找不到最优解；代码规范意识有待加强，有时为了赶进度忽略注释和命名规范。在后续学习中，我计划通过刷算法题和参与开源项目，提升逻辑思维和代码质量。
对于课程学习，我建议增加更多小组讨论环节，通过交流碰撞出思维火花。在作业布置上，可以提供一些扩展性任务，鼓励我们探索更多实现方式。实验课如果能增加代码评审环节，让同学们互相学习借鉴，相信会有更大收获。
这段学习经历不仅是一次技术上的积累，更是对毅力和耐心的考验。未来的编程之路还很长，我会带着这些宝贵经验继续前行，迎接更多挑战。