第三次Blog作业--总结性Blog

目录

一、前言

二、面向对象技术总结

三、采坑心得

四、改进建议及总结

一、前言

Blog作业：

工作量： 较大，总是在PTA题集迭代完事儿后才要写一篇，内容也很多（前言：总结题目集的知识点、题量、难度等情况。设计与分析：参考SourceMontor的生成报表内容以及PowerDesigner的相应类图，要有相应的解释和心得（做到有图有真相）。采坑心得：对源码的提交过程中出现的问题及心得进行总结，务必做到详实，拿数据、类设计结构、流程图及测试结果说话，切忌假大空。改进建议：对相应题目的编码改进给出自己的见解，做到可持续改进。总结：对本阶段题目集的综合性总结，学到了什么，哪些地方需要进一步学习及研究，对教师、课程、作业、实验、课上及课下组织方式等方面的改进建议及意见），但是三次迭代后再过一周已经忘记了当时的思路和想法，每次写的时候都点看着代码绞尽脑汁的想当时写的时候都干啥了，什么想法，什么思路，需额外花费时间整理思路与代码片段。
难度： 基础，主要针对逻辑表达，写题思路的重新梳理，适应技术写作规范，对面向对象设计原则（封装、继承、多态）的深度理解，专业术语的准确等等等......

PTA作业：

工作量： 中等，一开始电梯我觉得挺难的，电梯的逻辑看不明白，绞尽脑汁的写啊，那段时间都有点怀疑人生了，电梯之后的题目集挺好，没有了奇奇怪怪的逻辑的“束缚”，终于守得云开见月明，我！又活过来了！每周我会选两三天去登录PTA做题，题目的迭代主要是从代码健壮性和可维护性，这和老师在课上讲的各种原则很符合，我个人感觉要先听老师的课，之后再写迭代就会很轻松（前提是不碰到电梯那种规则的“阅读理解”题）。
难度： 较难，机试评分严格，注重细节，如输入输出格式、边界条件的处理等，而且测试点少，有的时候例子全对，但是运行就是显示不对，而且PTA和IDE有差别，做题的时候在eclipse先写，可以运行并且结果都正确，但是复制到PTA上就显示答案错误，我真纳闷儿了，在PTA上写又太笨，真*进退两难。

实验：

工作量： 较大，因为有特意为实验开设的实验课，让我们有确定的集中的时间去写实验，让我们的工作量大大减小，但是实验提交系统不让复制粘贴，还必须用校园网，系统也没有什么很多的功能，一开始那个代码打上去的时候字体还怪怪的，又黑又密，对眼睛的攻击maxmax，每天打那个字打的我sun值狂掉，每次写实验，好不容易打完，结果错误很多都让我在发疯边缘疯狂试探，我只能说，工作量是挺大的哈。
难度： 中等，实验的实施挺麻烦，毕竟有很多都没学过，要自己去上网学，其实挺累的，实验报告还可以，把实验过程写上就行，那个实验代码提交挺难。

线上课程：

工作量： 中等偏少，和老师讲的差不多，工作量还行。
难度： 基础，就是那个课后的题，答案一板一眼的，少一个字不行多一个字也不行，爱就一个字 ~ 我只说一次 ~，六。

线下课程：

工作量： 较为轻松，我只能说，我大爱蔡老师！老师从来不会对我们采用强制手段，每次讲课也很幽默，很能带动我，讲的也很通俗易懂，而且每次讲完之后还会带着我们做习题，我们不会也会乐呵呵的而且很耐心的讲解！上蔡老师的课让我很快乐，完全不觉得工作很多，也不会有很沉重的感觉。
难度： 基础，我觉得老师讲的很好，有很多例子帮助我们理解抽象的概念，就我个人而言，难度不是很大，好，好，好!

二、面向对象技术总结

对封装、继承、多态、抽象类、接口、集合框架、异常以及JavaFX等相关内容掌握情况

对各部分技术的认知：

封装：将类的属性和方法包装在一起，通过访问控制符（private、protected、public）隐藏内部实现细节，仅对外提供必要的访问接口。使用private修饰属性，防止外部直接访问。通过public的getter/setter方法控制属性读写。封装是面向对象的基础防护机制，避免外部对数据的非法操作。
继承：子类（派生类）继承父类（基类）的属性和方法，实现代码复用与扩展，通过extends关键字实现。类拥有父类的非私有成员，可重写父类方法。Java 中类只能继承一个父类，但可实现多个接口。继承通过 “is-a” 关系简化代码复用，但需注意避免过度继承导致的耦合问题。
多态：同一方法调用可表现出不同行为，通过继承重写、接口实现或方法重载实现。父类引用指向子类对象，运行时根据实际对象类型调用方法。同一类中方法名相同但参数列表不同（如add(int a, int b)与add(int a, int b, int c)）。多态是框架设计的核心，如 Spring 框架的依赖注入基于多态思想。
抽象类：用abstract修饰的类，包含抽象方法（仅有声明无实现），不能实例化，需子类实现抽象方法。抽象方法：必须在子类中实现。普通成员：可包含普通方法、属性和构造器（用于子类初始化）。
接口：用interface声明的抽象类型，包含常量（public static final）和抽象方法。多实现：类可通过implements实现多个接口，接口间可继承（extends）。行为定义：接口定义 “能做什么”（如Flyable接口），而非 “是什么”。
集合框架：Java 中用于存储和操作数据的类库，核心接口包括Collection和Map。ArrayList基于数组实现，随机访问效率高；LinkedList基于链表实现，增删效率高；HashMap通过哈希表实现，键唯一且查询时间复杂度为 O (1)。
List：有序可重复，如ArrayList（数组实现）、LinkedList（链表实现）。
Set：无序唯一，如HashSet、TreeSet。
Map：键值对存储，如HashMap、TreeMap。
异常：程序运行时出现的错误，分为编译时异常（受检异常，如IOException）和运行时异常（非受检异常，如NullPointerException）。异常处理：使用try-catch-finally捕获处理，或用throws声明抛出。自定义异常：继承Exception或RuntimeException创建自定义异常类。异常处理应遵循 “具体捕获、分层处理” 原则，避免使用catch (Exception e)捕获所有异常；finally块中的代码无论是否发生异常都会执行，常用于资源释放（如文件流关闭）。
JavaFX：掌握Button、TextField、Label等控件的创建与事件监听（如button.setOnAction(e -> System.out.println("点击"))）。使用BorderPane、VBox、HBox等布局容器设计界面结构，理解FXML文件与 Java 代码的绑定方式。通过Scene和Stage构建窗口应用，实现界面跳转（如登录页到主界面的切换）。JavaFX 支持样式定制和动画效果。

哪些技术掌握有欠缺：

我对其他的还好，但是对集合框架心里没底，可能是在之前的学习中集合队列这类给我留下了心理阴影，看到这玩应就发怵，掌握的感觉忽高忽低的，还有就是javafx，只学了大概，对更加细节的部分可能略有欠缺。

三、采坑心得

编码路上的那些 “坑”：一个程序员的血泪手记

第一个坑：沉默的代码像本 “无字天书”
第一次写电梯调度程序时，我对着屏幕上密密麻麻的代码发了呆 —— 那些控制电梯状态转换的逻辑，明明上周才敲完，此刻却像陌生人一样陌生。当时总觉得注释是 “多余的墨水”，方法名和变量名能看懂就行，结果在调试一个死循环 bug 时，愣是花了两小时重新梳理idle到running的状态跳转条件。后来才明白，注释不是写给机器的，是留给一周后抓耳挠腮的自己：当我在代码里写下 “// 当电梯无请求且当前楼层为 1 时进入空闲状态”，第二天复查时能瞬间找回思路，这比对着if (floor == 1 && requestList.isEmpty())发呆高效太多。

第二个坑：PTA 上的 “包声明幽灵” 与非零陷阱
PTA 的编译错误页面曾是我的噩梦。有次写完 “学生管理系统”，自信满满地复制代码提交，却收到 “找不到主类” 的提示 —— 定睛一看，本地代码的package com.xxx;忘了删，在 PTA 的默认包环境里成了 “异物”。更憋屈的是非零返回：一次写数组排序方法，循环条件错把i < n写成i <= n，数组越界异常让程序提前以return 1结束，而我盯着 “答案错误” 的提示框，直到用调试器看到异常堆栈才恍然大悟。后来我养成了提交前 “Ctrl+F” 搜索package的习惯，主方法最后也必定加上return 0，就像出门前检查门锁一样。

第三个坑：输入输出的 “格式迷宫” 与临时抱佛脚
“多项式计算” 作业让我深刻体会了 “先规划后编码” 的重要性。起初没细看题目要求，把输入格式 “3 2”（3x²）想当然处理成 “3,2”，等写完大半代码才发现解析逻辑全错，不得不推翻重来。最惨的是有次作业截止前两小时才动笔，对着 “每行输入以空格分隔，行末无多余空格” 的要求手忙脚乱，结果输出时多打了个空格，在 PTA 上反复 “Wrong Answer”。后来我学会了用铅笔在草稿纸上画输入输出流程图：先标清楚 “输入行→分割字符串→转换数值” 的步骤，再用样例数据走一遍流程，就像旅行前查好地图，再也不会在格式迷宫里迷路。

第四个坑：时间管理的 “拖延怪圈” 与连锁反应
有段时间总把作业拖到截止前一天才动手，结果 “银行账户系统” 作业那晚，我在键盘前上演了 “速度与激情”：为了赶时间，把余额判断条件if (balance >= withdraw)写成了if (withdraw >= balance)，直接导致账户透支；调用Scanner的nextInt()后没接nextLine()，还让输入光标卡在了换行符上。更致命的是没给转账方法加注释，第二天老师让讲解代码时，我指着transferMoney方法支支吾吾，完全记不起当初为何要在循环里加那个try-catch。现在我手机里存着个 “作业倒计时” 表格，每阶段完成就打勾，就像给代码加上了 “时间安全带”。

第五个坑：编译错误的 “隐形陷阱” 与逻辑盲区
那些看似微小的编译错误，曾让我在 IDE 里反复 “clean+build”。有次把Scanner拼成Scannar，报错 “找不到符号” 时还以为是环境问题；在同一个 Java 文件里写了两个public class，编译时才知道 “一山不容二虎”。最让我捶胸的是私有成员访问错误：在Main类里直接写student.privateScore，被 IDE 红线警告后才想起封装原则，不得不给Student类添加getScore()方法。而逻辑漏洞更像 “隐藏的地雷”：写 “求最大公约数” 时，只测试了a > b的情况，没考虑a < b时循环会直接跳过，直到 PTA 的 “边界测试点” 让我栽了跟头。现在我养成了 “写完代码先编译” 的习惯，就像开车前检查轮胎，能提前碾过大部分 “小石子”。
这些坑像编程路上的坐标，标记着每一次 “哦，原来这里该这样” 的顿悟。当我学会给代码加注释、用流程图规划逻辑、在 PTA 提交前多检查三遍时，才发现所谓 “编程经验”，不过是把别人踩过的坑，变成自己脚下的垫脚石。

四、改进建议及总结

编码路上的填的“坑”：从踩雷到避雷的成长手记

第一个坑的救赎：给代码写一封“介绍信”
当我对着三周前写的电梯调度代码发呆时，终于明白注释不是可有可无的“墨水”，而是代码的“自我介绍”。现在我养成了怪癖：每写完一个方法，就像给新朋友写名片一样加上文档注释——/** 计算电梯从当前楼层到目标楼层的运行时间，返回秒数 */，这样下次见面时，它会清晰告诉我“我是做什么的”。遇到复杂的循环逻辑，我会在代码块前插一句“// 处理所有上行请求”，就像在迷宫路口贴上路标。最神奇的是，当我给if (floor == 1 && requestList.isEmpty())加上“// 电梯无请求且在1楼时进入空闲状态”的注释后，连同桌都能看懂我的代码逻辑了——原来注释是程序员之间的秘密语言，能让沉默的代码开口说话。

第二个坑的突围：PTA提交前的“三重安检”
被PTA的“包声明幽灵”坑过三次后，我手机备忘录里多了个固定模板：“提交前必做三件事——查package、删多余空行、验返回值”。现在每次复制代码到PTA，我都会先在记事本里新建文件粘贴，就像给代码“卸妆”，去掉本地环境的“妆容”；主方法最后必定加上return 0，就像出门前检查门锁是否锁好；输出时改用System.out.printf("%d\n", result)，用格式化字符串精准控制格式，再也不怕多一个空格。最妙的是调试时发现的“本地模拟法”——在IDEA里新建无包类，用java Main < input.txt模拟PTA的输入环境，那些在本地运行正常却在PTA报错的“玄学问题”，从此少了大半。

第三个坑的破局：先画“施工图纸”再盖楼
多项式计算作业让我学会了“先规划后动笔”的智慧。现在拿到题目，我会先用铅笔在草稿纸画“输入处理流程图”：输入行→按空格分割→转换为数值→校验合法性，每个步骤像乐高积木一样标清楚。遇到复杂的输入格式，我会把样例数据抄下来，手动模拟程序运行过程，比如“当输入是‘3 2’时，第一步分割成‘3’和‘2’，第二步转成int型，第三步判断指数是否为正”。最关键的是提前预判“坑点”——在图纸角落画个醒目的问号：“如果输入是‘0 0’怎么办？”“如果输入是‘3a 2’怎么办？”这样编码时就像带着地图探险，再也不会在格式迷宫里绕圈子。

第四个坑的逆袭：给时间上一把“进度锁”
被作业截止日期追着跑的日子里，我摸索出了“48小时作战计划”：第一天用1小时画类图，就像搭房子先立框架；第二天上午写核心方法，下午专门写测试用例，就像砌墙后检查是否牢固；最后4小时留作“扫雷时间”，专门调试边界情况。现在手机里有个“作业倒计时”备忘录，每完成一个阶段就打个勾，就像游戏里解锁成就。最意外的收获是“番茄钟工作法”——把25分钟设为一个战斗单元，专注写输入模块时，连微信消息都顾不上看，效率比之前翻倍。当我提前两小时完成“银行账户系统”作业，悠闲地调试代码时，终于明白：时间不是被节省的，而是被规划出来的。

第五个坑的防御：给代码穿上“防弹衣”
那些让我捶胸顿足的编译错误，现在成了我的“编码警报器”。IDE被我调成了“严苛模式”，只要有拼写错误（比如Scannar）、多余的public类，立刻红线警告；我还在笔记本里抄录了“错误黑名单”：“调用方法必加括号”“私有成员必用getter”“导入包必检查”，每次写代码前都会扫一眼。对付逻辑漏洞，我学会了“测试用例轰炸法”——写完“求最大公约数”方法，不仅测a=6,b=4，还专门测a=0,b=5、a=3,b=7，就像给代码做“压力测试”。最神奇的是单元测试——当我用Junit给转账方法写了10个测试用例后，那些藏在角落里的边界错误，自己就蹦出来了。

终章：坑洼路上的星光
回头看这些被填平的坑，忽然发现每个改进建议都是一颗星星——注释是照亮代码的灯，流程是指引方向的路标，规划是搭建桥梁的蓝图，时间管理是丈量进度的标尺，防御性编程是抵御风雨的盔甲。现在的我不再害怕遇到新坑，因为每个坑都是成长的刻度：当我学会给代码加注释时，其实是在培养逻辑表达能力；当我严格遵守PTA提交流程时，其实是在打磨工程化思维；当我提前规划输入输出时，其实是在训练系统设计能力。这些填坑的过程，最终让编程从“踩雷冒险”变成了“铺路旅行”——每解决一个问题，就像在编程之路上铺下一块坚实的砖石，通向更远的地方。

这也许是我Blog上的最后一次作业，但我相信，这绝对不是我最后一次的反思和总结。