第三次博客作业

前言

本学期的课程学习中，博客作业的难度相对友好，多以学习总结与思维反思为主，能帮助我系统梳理知识脉络。但PTA题目集与大作业则颇具挑战性——第一次大作业聚焦电梯运行逻辑与LOOK算法，从轿厢的上下行调度到多楼层请求的优先级处理，大量逻辑判断与算法实现让我在反复调试中深刻理解了调度系统的设计逻辑，尤其是状态机转换与边界条件处理时，常常需要逐行推敲代码逻辑。第二次大作业虽思维复杂度稍有降低，却着重考察Java基础语法与面向对象编程的核心能力，从类的封装设计到接口的多态应用，每一个模块的搭建都在强化我对抽象类、继承关系的实际运用能力。

实验环节则呈现出递进式的难度设计，从基础语法验证到综合功能实现，每一次实验都像是在知识阶梯上的稳步攀登，尤其在多线程同步与数据结构优化的实验中，通过不断调试与查阅资料，逐渐掌握了并发控制与算法优化的技巧。线上线下课程的结合也让人印象深刻，线上慕课的预学习能提前构建知识框架，线下课堂的互动讨论则让抽象概念变得具象化，特别是在电梯算法的分组研讨中，同学间的思路碰撞让我对复杂问题有了更全面的理解，这种理论与实践结合的学习模式，确实让知识吸收更加扎实。

面向对象技术学习总结

这学期学面向对象程序设计这门课，可算是把Java里的各种技术“摸了个遍”。从一开始的封装，到后来的多态和JavaFX，每一步都踩过坑也有收获，下面就来说说我的真实感受。

一、封装：给数据加个“保险箱”

刚学封装的时候，我很疑惑：为什么非得把属性藏起来，搞那么多getter和setter方法？在写代码时，我直接把学生成绩设成了公共属性，结果后续写成绩修改功能，全班成绩都跟着出了乱子——其他同学的成绩莫名其妙被篡改了。后来才知道，这就是没封装好，数据随便被外部修改的后果。

从那之后，我就记住了：封装就像给数据上了把锁。比如在做图书管理系统的实验，我把图书编号、库存数量都设成私有，只能通过专门的方法修改。虽然写代码时多敲了几行，但程序稳定性强多了，再也没出过数据错乱的问题。不过遇到复杂业务，比如大作业里电梯状态的封装，我还是拿捏不好分寸，有时候方法设计得太细，反而把代码搞得更复杂了。

二、继承和多态：偷懒和“开挂”的神器

学继承那会儿，我可算是尝到了甜头。在图形计算的PTA作业里，我先写了个抽象的“图形类”，里面留了计算面积的抽象方法。后面写圆形、矩形类的时候，直接继承这个父类，再各自重写面积方法，代码量少了一大半。

多态更有意思，就像给程序开了“外挂”。在模拟宠物叫声的实验里，我定义了“宠物类”，让“猫类”“狗类”继承它。调用叫声方法时，不管传进来的是猫还是狗的对象，程序都能自动调用对应的叫声，特别灵活。不过到了大作业，在处理电梯不同类型请求时，我因为没理清继承关系，导致代码出现了重复逻辑，debug了好久才解决，说到底还是对多态的理解不够深。

三、抽象类和接口：给代码立规矩

抽象类和接口，一开始我老是搞混。直到做“支付系统”实验，我才弄明白它们的区别。我把“支付方式”定义成抽象类，里面有“支付”抽象方法，让“微信支付类”“支付宝类”去继承；又定义了“退款接口”，让这些支付类实现。这样一来，支付和退款功能既统一规范，又能各自实现特色逻辑。

但实际用起来，我还是会纠结：到底该用抽象类还是接口？有次为了省事，把本该用接口的地方写成了抽象类，结果后续扩展新功能时，代码改得一团糟。后来我才意识到什么时候用抽象类，什么时候用接口，还要结合具体需求反复琢磨。

四、集合框架：装数据的百宝箱

集合框架绝对是我用得最多的工具。ArrayList就像一个能随意扩容的袋子，在统计班级成绩时，用它存学生分数，添加、删除都特别方便。

不过集合用起来也有坑。有次在PTA作业里，我用ArrayList存对象，结果删除元素时忘了索引会变化，导致漏删了数据。这些教训让我明白：集合虽然好用，但细节不注意，分分钟就会出bug。

五、异常处理：给程序“兜底”

异常处理刚开始学觉得挺简单，不就是try - catch嘛。在处理用户输入的作业里，我用try - catch捕获输入格式错误，程序确实没崩溃，但提示信息写得太笼统，用户根本不知道错哪儿了。后来在实验里做文件读取功能，我才知道要在catch块里打印详细的异常信息，方便自己排查问题。

在大作业电梯系统里，异常处理更重要。要是电梯运行时突然“卡壳”，没处理好异常，整个系统就瘫痪了。/但是当时还没学，没用上/doge//不过自定义异常类这块，我还是不太会设计，感觉这部分还得再下功夫。

六、JavaFX：又爱又恨的界面工具

JavaFX对我来说，真是“爱恨交加”。第一次用它做计算器界面，拖拖拽拽按钮、文本框，还挺有成就感。可到了可视化界面，我彻底懵了。而且JavaFX和后端逻辑整合也特别麻烦，数据更新和界面显示老是不同步，但是功能确实很强大，比起开学时候用到的EGE还是要好用很多。

现在回头看，这门课学的每项技术都像一块拼图，单独看好像用处不大，但拼在一起，就能做出功能丰富的程序。虽然还有很多技术我没吃透，不过至少入了门。以后再遇到类似问题，心里也有了大概的解决方向，这大概就是这学期最大的收获吧。

踩坑心得

回顾这学期面向对象编程的学习，在 PTA 作业和大作业里栽过不少跟头，这些教训反而让我把知识点记得更牢了。

第一次栽跟头是在 PTA 做学生信息管理作业。
当时对封装理解不深，偷懒把学生成绩属性设成公开的，想着直接读写多方便。结果在写成绩修改功能时出问题了，外部能随意访问和修改数据，没有任何限制，导致数据全乱了。这次让我记住了：封装不是多此一举，它就像给数据上了把锁，能保证程序稳定。

第二次是做大作业的电梯运行系统。
涉及到电梯调度逻辑和 LOOK 算法，我一开始想得太简单，没把电梯运行的各种状态和请求优先级捋清楚。写代码时全把逻辑全堆在一个类里，结果代码又长又臭。测试时发现，电梯经常出现不该停的楼层停了，该响应的请求没响应的情况。后来硬着头皮重新梳理逻辑，把电梯状态管理、请求处理拆分到不同类里，还专门画了流程图理清执行顺序，这才让电梯 “正常工作”。这次经历让我明白：复杂功能一定要先做好模块划分和逻辑设计，不然写到后面就是一团乱麻，改都没法改。

第三次是做大作业的航空货运管理系统。
经过了这次作业的拷打，我终于明白了几个道理
1.逻辑设计忌 “想当然”：计算类题目容易忽略单位转换、边界条件等隐含规则，比如运费计算时未统一尺寸单位导致结果错误。以后要逐字核对题目要求，公式计算必须加注释，并测试边界值。
2.类职责需清晰分离：代码重构时，一个类不能同时承担计算和展示功能，像 Goods 类混写运费计算和输出逻辑，后续扩展新需求时改得一团糟。应按功能拆分，让每个类只做一件事。
3.输出格式细节决定成败：小数精度、对齐方式等格式问题最容易丢分，比如没控制小数位数、表格字段错位。调试时要先固定格式再填充数据，复杂表格可以先写文本模板再转代码。
4.多态别盲目用继承：实现用户折扣功能时，用继承区分用户类型导致代码重复。其实用策略模式把折扣逻辑单独抽成接口更灵活，能避免子类臃肿，方便后续加新折扣规则。

改进建议及总结改进建议及总结

总结：从混沌到有序的成长

回望这一学期的面向对象程序设计课程，仿佛经历了一场从“机械码农”到“设计者”的蜕变。初学时，面对封装、多态等概念，如同手持拼图却不知全貌；而今，已能将这些技术融会贯通，搭建出结构清晰、功能完整的系统。课程如一座桥梁，将书本上的抽象理论化为指尖下的生动实践，而PTA的锤炼、大作业的拷打、实验的步步为营，则让我在调试与重构中真正领悟了“面向对象”的精髓——不是代码的堆砌，而是思维的雕塑。

建议：
线上：在慕课中嵌入“即时问答彩蛋”，例如播放到多态案例时，弹出选择题：“以下代码输出什么？A.喵 B.汪 C.编译错误”，答对解锁趣味注释，增加学生的参与感。
线下：开设“Bug诊疗所”——学生提交匿名问题代码，课堂集体“会诊”，教师引导分析错误根源，让错误成为最佳教材。
原因：作业反馈周期较长，学生易重复同类错误；大作业缺乏中期进度校准。
建议：多发几次PTA作业，让学生的代码“手感”不生疏。
结语：这门课如同一本精心编写的程序：教师是架构师，用清晰的逻辑搭建知识框架；作业是测试用例，暴露出我们的薄弱环节；而实验则是调试过程，让我们在反复修正中逼近完美。若说还有什么期许，便是希望这份“代码”能持续迭代——多一点互动，少一点孤独；多一点引导，少一点迷茫。
（文末彩蛋：用一行代码总结本学期？）
while(困惑) { 顿悟++; } return 成长;