第三次blog作业
第三次blog作业
一、前言
对这门课程的总结:
首先，对于blog作业，我觉得这门作业谈不上有难度吧，但我觉得这个作业是很有意义的，能及时帮助我们总结我们所学到的知识，让我们充分认识到自己的不足。
PTA 作业是两颗星的中等分量，题量三到五题，周期七日至旬余。若熟稔了知识点，一个下午便能织就代码的经纬，再花两三天细细熨帖结构，倒像梅雨时节的光阴，不疾不徐。只是头回电梯迭代题如骤雨，难度窜至三星，叫人握笔时多了几分凝重。
实验最是令人喟叹，五星的工作量沉甸甸压在肩头。手写数百行代码，错漏如残荷上的雨珠，寻一个大括号的缺失便能耗去两个时辰，再加上实验报告的笔墨，真像是背了一筐月光行走。好在难度尚属三星，只消把实验要求嚼碎了咽下去，便能在代码的阡陌里走出路径。
线上课是一星的清闲，倍速播放如流水划过石阶；线下课每周三节，老师的语速似夏日急雨，内容如雾中青山，量是二星，难却到了三星，需得捧着笔记反复摩挲，才得见几分真容。
这般课业的滋味，原是要在晨光与灯影里，慢慢品出些回甘的。
二、面向对象技术总结
这半年来学那面向对象的学问，终究是有些长进了。从 PTA 作业到实验课，像是走一条长长的路，一步一步踏在封装、继承、多态的石子路上，如今回头看，竟也留下了几行深浅不一的脚印。
先说那封装罢。头回做 PTA 的电梯题时，只觉得这 "封装" 二字玄乎得紧，像是把物件收进箱子里，却不知从何下手。后来才明白，类便是那箱子，把数据和方法锁在一处，外头只留几个接口使唤。就像实验里写那学生管理系统，把姓名、学号都藏在类里头，只露个修改信息的方法给外界，倒真像是老掌柜守着柜台，只把该给人看的递出去。这功夫靠的是多练，做过三回 PTA，便渐渐懂得如何把物件封得严实，不叫里头的东西乱了套。
继承这事儿，起初觉得像极了家族里的传家本事。父类是老辈儿，子类得了真传还要添些新花样。记得有回做实验，写一个 "形状" 父类，底下派生出 "圆形"" 矩形 "，父类里的" 计算面积 " 方法到了子类便各有各的算法，倒像是老子种田，儿子学会了还会用机器耕地。只是头回写时总闹笑话，不是忘了调用父类构造器，便是多写了重复的代码，后来在 PTA 里反复打磨，才晓得如何让子类顺顺当当接上父类的脉络，不似起初那般手忙脚乱。
多态这概念最是有趣，像是戏台上的角儿，同一个招式能变着法儿使。记得 PTA 里有个题目，用父类引用指向子类对象，同样的 "绘图" 方法，圆形画圆，矩形画方，运行时才晓得要使哪般招式。这就好比见了人说 "吃了么"，南方人回 "吃了"，北方人回 "咋才吃"，话虽同，意思却各有不同。实验里写接口时更觉得奇妙，一个接口多个实现类，真像是一把钥匙开多把锁，全看锁芯的构造。
如今想想，这面向对象的学问，原不是一下子能懂的。好比爬山，起初只看见石头树木，爬得高了，才晓得山的走势、树的脉络。PTA 的题目像是山脚的石子，实验课便是半山的台阶，一步一步走过来，虽时常摔跟头，到底是离山顶近了些。往后若再遇着难题，少不得拿出这些日子练的功夫，像老吏断案般，把封装、继承、多态的法子一一摆出来，总要寻出个解法来才好。
1.封装
咱在PTA作业和实验里摸爬滚打这些日子，算明白封装这事儿就跟老北京四合院似的——把要紧的东西都圈在里头，外头人瞧不见也摸不着，非得走正门儿才能打交道。就说那航空货物管理系统的实验吧，我把货物的名儿、编号、长宽高这些个家底儿全藏起来，跟藏私房钱似的，只在外头开了俩小门儿（getter和setter）让人递话。这么着，数据就跟宅门里的姑娘似的，安全得很，外头人想瞎鼓捣可不成，这便是封装的妙处。
起初学这玩意儿，咱就跟初到京城的乡下小子，瞅着四合院的门庭眼生得很。常把属性的访问权限闹混了，跟分不清前门后门似的，让数据没了规矩。后来做一回作业便多懂一分，好比拉洋车的伙计，跑得趟数多了，哪条道儿顺溜心里就有数了。可到了复杂的业务逻辑里，咋把方法和属性归置得妥妥帖帖，还真得费些脑筋。就像老北京的胡同，看着都差不多，可哪条能通到主街，哪条是死胡同，没个几年琢磨不成。
封装这事儿，说到底是把数据和使唤数据的法子捆在一块儿，跟豆包似的，皮儿裹着馅儿，外头人吃不着馅儿，只能咬皮儿。如今咱算是摸着点门道了，可离着“高内聚低耦合”这境界还差着老大一截呢。就像咱老说“吃饺子得蘸醋”，可真要调出那酸甜合适的味儿，还得跟老师傅学个三年五载不是？往后做实验还得再多琢磨，让这封装跟咱使唤自个儿的手似的，顺溜、得劲儿，才算真学成了。
2.继承
在面向对象技术的学习征程中，继承之意义重大，实现代码复用之关键利器。其能极大削减代码冗余，此功效仿若精兵简政，让程序更为高效、轻便，亦契合人类认知与思维的自然模式。
以实验里那“将不同动物装进不同电器”的任务为例，此过程对继承关系的运用堪称精妙。彼时，我精准定义了电器类与动物类作为父类，悉心归纳并实现了这两类事物共有的方法与属性。这般操作，就如同为后续构建复杂系统奠定了坚实的基石，子类可顺理成章地从父类汲取养分，复用其代码。子类恰似父类的新生力量，在继承的基础上，可根据自身特性进一步拓展与细化，实现个性化的功能。如此一来，既减少了重复劳动，又让整个代码体系呈现出清晰的层次结构，条理分明，便于理解与维护。
然而，在运用继承这一强大工具时，我亦遭遇诸多挑战。有时继承关系过度复杂，宛如盘根错节的荆棘丛，使得代码维护难度剧增，牵一发而动全身，一处修改便可能引发一系列意想不到的问题；在方法重写过程中，权限问题也常如拦路虎一般，阻碍代码的顺利推进，若权限设置不当，程序便无法按照预期运行。目前，我对继承的基本操作已较为熟稔，如同初上战场的战士，已掌握了基本的战斗技巧。但在优化继承结构、规避继承导致的代码复杂性方面，以及精准判断何时该运用继承关系等关键问题上，我仍存在明显不足，恰似在复杂战局中，还未能精准把握战略要点。这恰似革命事业中，虽有一腔热血与初步经验，但面对复杂局势，还需不断磨砺与学习，方能游刃有余。我深知，后续必须持续钻研、深入实践，方能真正将继承这一强大技术运用得炉火纯青，在面向对象编程的领域中闯出一片广阔天地 。
3.多态
在 PTA 的 "点线面" 题目中，多态的应用体现得淋漓尽致。我首先定义了基本元素抽象父类，继而通过继承机制构建了点类、线类、面类等具体图形子类。在展示这些图形元素时，通过抽象类引用指向具体子类对象，调用统一的展示()方法，系统会根据对象的实际类型执行差异化的展示逻辑，充分发挥了多态的技术优势。
这种动态绑定机制显著提升了代码的灵活性与可扩展性：当需要新增图形类型时，仅需创建新子类并实现对应的绘制方法，无需修改原有代码结构，体现了 "开闭原则" 的设计思想。在多次 PTA 作业实践中，我逐渐掌握了多态的应用范式，但在处理复杂的多态层次结构（如多层继承与接口实现交织）及方法重载场景时，仍存在概念混淆的情况，对多态在泛型编程、设计模式中的深层次应用仍需进一步深化理解。
4.抽象类
抽象类如同建筑设计中的蓝图，是一种不能直接建造（实例化）的概念模板，其核心作用是为子类划定必须遵循的结构框架（抽象方法），同时提供可复用的通用设计（具体方法与属性）。以PTA题目中的图形体系为例，Element抽象类就像提炼了点、线、面共同特征的"图形基因图谱"——它定义了所有图形必须具备的display()抽象方法（如同规定蓝图中必须标注尺寸），同时包含color、position等共享属性（如同建筑图纸中通用的材料标注）。
这种设计机制可类比生物分类体系："动物"是抽象概念的集合，它拥有"名称""体重"等共性特征（抽象类的属性），却无法直接存在于现实中；而大象、狮子等具体动物（子类）继承了"动物"的共性，同时实现了独特的行为（如大象的trumpet()、狮子的roar()方法）。抽象类强制子类履行"契约"——就像蓝图要求所有建筑必须包含门窗结构，子类必须实现抽象方法才能完成具体"建造"。当程序中使用Element element = new Point()时，本质是用蓝图标准（抽象类引用）来规范具体实现（子类对象），既保证了类型体系的一致性，又为扩展新图形（如Circle类）预留了"按图施工"的接口。
简言之，抽象类是面向对象设计中的"规则制定者"：它不生产具体对象，却通过定义"必须做什么"（抽象方法）和"可以怎么做"（具体方法），为子类构建了从概念到实现的完整路径，如同用模具浇灌混凝土，让复杂系统的构建拥有清晰的范式指引。
5.接口
作为面向对象设计中的 "契约制定者"，抽象类在课程实践中扮演着规范架构的关键角色。以航空货物管理系统为例，我设计的抽象支付类犹如定义了支付体系的 "行业标准"—— 其中声明的支付()抽象方法如同要求所有支付方式必须遵守的 "接口协议"，而抽象类本身则封装了支付金额、交易时间等共性属性，为具体支付方式提供了基础数据结构。
在该系统中，微信支付类与支付宝支付类作为抽象类的具象化实现，既继承了统一的支付流程框架，又各自实现了差异化的支付逻辑（如微信的调用微信接口()与支付宝的生成支付二维码()）。这种设计清晰剥离了支付体系的共性特征与个性实现：共性部分（如支付状态校验、金额验证）在抽象类中统一处理，个性部分则交由子类定制，如同电商平台制定统一的支付接口规范，而不同支付渠道自行实现底层对接。
在实践中，抽象类的设计面临着 "契约粒度" 的权衡挑战：哪些方法需强制子类实现（抽象方法），哪些可提供默认实现（具体方法），哪些属性应作为公共基础（抽象类属性）。例如在支付场景中，计算手续费()是否定义为抽象方法，需取决于不同支付方式的计费规则差异程度。当前对抽象类设计的理解仍停留在 "形式化继承" 层面，尚未完全掌握 "领域驱动设计" 中抽象类与业务模型的映射原则，需在后续实践中结合 SOLID 原则，深化对抽象类 "接口隔离"" 依赖倒置 " 等设计理念的应用能力。
6.集合框架
在面向对象编程实践中，集合类可视为封装完善的工具组件库，其设计遵循 "场景适配" 原则，能根据不同业务需求提供针对性的数据结构解决方案。以电梯调度算法为例，采用LinkedList实现楼层队列管理，充分利用了其双向链表结构在顺序添加、中间插入场景下的效率优势；而Map接口的键值对映射机制，在乘客请求与楼层索引的关联场景中，通过key的唯一性快速定位数据，显著简化了查找逻辑，体现了 "数据结构服务于算法" 的设计思想。
当前对集合体系的掌握仍存在认知盲区：Set接口的无序性与唯一性特性（如HashSet的哈希散列实现、TreeSet的红黑树排序）在实际业务中的应用场景识别能力不足，尚未熟练掌握Map接口的entrySet()遍历范式与computeIfAbsent()等函数式方法的高阶用法。迭代器机制的理解停留在hasNext()/next()的基础调用层面，对ConcurrentModificationException等并发访问异常的处理逻辑、ListIterator的双向遍历特性缺乏深入实践。
后续需系统梳理集合框架的继承谱系（如Collection接口→List/Set子接口→具体实现类），结合 LeetCode 数据结构题目强化Set的去重场景（如数组元素唯一性判断）、Map的频率统计（如单词词频分析）等典型应用，通过源码级分析（如HashMap的负载因子机制、LinkedHashSet的链表维护策略）深化对迭代器设计模式（Iterator接口）与集合底层实现的理解，逐步构建从 "工具使用" 到 "原理掌握" 的完整知识体系。
7.异常
异常处理机制作为程序健壮性的 "安全网"，在航空货物管理系统的文件读写模块中展现出关键价值。当面对文件不存在（FileNotFoundException）、读取校验失败等异常场景时，通过try-catch-finally的结构化处理框架，可实现异常场景的系统化管理 —— 例如在文件读取流程中，通过try块包裹核心 IO 操作，catch块针对性处理不同类型异常（如权限异常SecurityException、格式异常IOException），并在finally块中确保资源释放（如关闭FileInputStream），有效避免程序因突发性错误而崩溃。
为适配业务逻辑的特殊性，自定义异常类（如CargoFileFormatException）的设计进一步提升了异常处理的精准度 —— 当系统检测到货物数据格式不匹配时，抛出携带具体错误信息的自定义异常，使上层调用链能基于业务场景进行针对性处理。这种 "标准异常 + 自定义异常" 的分层处理模式，如同机场安检的 "常规检查 + 特殊筛查" 机制，既覆盖通用异常场景，又能定位业务特有的错误节点。
当前异常处理实践中存在两类典型问题：一是 "异常捕获策略失衡"，如在底层 IO 操作中过度使用catch (Exception e)进行泛化捕获，掩盖了具体异常类型的诊断信息；二是 "异常传播层次混乱"，在服务层直接抛出底层IOException而未转换为业务异常，导致上层调用者需处理与业务无关的技术异常。这些问题本质上反映了对 "异常封装原则"（业务异常与技术异常分离）、"异常粒度控制"（按责任域划分异常处理层次）的理解不足，后续需结合Throwable类的继承体系（如RuntimeException与 checked exception 的使用边界），构建更科学的异常处理架构，使异常机制真正成为程序稳定性的保障而非负担。
8.javafx
JavaFX 作为现代 GUI 开发的强大工具，在航空货物管理系统的 PTA 项目中展现出卓越的可视化构建能力。我通过 JavaFX 搭建了兼具功能性与美观性的用户交互界面，集成窗口容器、操作按钮、数据输入框等基础组件，并借助事件监听机制实现了组件间的动态交互 —— 例如当用户点击 "货物查询" 按钮时，通过setOnAction事件处理器触发数据检索逻辑，将查询结果实时渲染到界面表格中，这种响应式设计显著提升了系统的交互体验。
特别值得一提的是，翻转课堂的学习模式为 JavaFX 的实践提供了独特的认知路径。通过自主设计界面原型、梳理布局逻辑并向同学讲解实现思路，我得以从 "使用者" 和 "设计者" 双重视角理解 JavaFX 的架构体系：在界面搭建阶段，运用BorderPane、GridPane等布局容器实现功能区域的合理划分；在交互逻辑层面，通过FXML标记语言分离界面定义与业务代码，践行 "关注点分离" 的设计原则。
三、踩坑心得
1.计算机是一门非常注重实践的学科，实践是检验真理的唯一标准，在这门学科体现的淋漓尽致，脑子"会了",手不会。。。
2.要注重对代码的理解，和适当对一些容器的底层进行了解，比如map容器。
3.在写代码前，要对整个程序有一个大概的框架，写一点算一点换来的只有事倍功半。。。
四、改进建议
迭代作业的测试点可以多给一些，更好对整个程序进行整体的理解。
五，总结
收获
- 编程基础能力提升
1.1正则表达式的工程化应用
1.2动态数据结构的灵活运用 - 面向对象设计入门
2.1类与对象的建模思维
2.2类间关系的设计实践
3.初步了解javafx - 问题拆解与逻辑实现
对于javafx的熟练度还非常不足，同时对于整体的设计能力还需继续训练。
浙公网安备 33010602011771号