第三次blog作业:对前面所有java作业的总结

各次作业总结:

对于每周的大作业部分我认为难度适中,一般每道题半小时之内都能做出来,但是对于少部分作业我认为还是有点问题体现在难度或者完成时间上。

pta作业:

在前三次的大作业中,pta作业一直是每周一次的频率,一般为四道题难度中等对于我们代码方面的锻炼是显而易见的有效,每周一次的pta作业不仅能够让我们巩固这些天以来学过的关于java方面的技术还能让我们练个手教我们不会手生,但是在足额也中的测试点不会进行相关的说明导致出错时不能高效的找到代码的欠缺以及问题。

实验作业

对于前五次的实验作业我认为是对我们代码应用方面很好的锻炼,将动物放进电器这个迭代的实验可以让我们每次编写代码时都自己思考去为下一次的代码的迭代做出铺垫,可以优化我们代码的可迭代性和可维护性,但是在提交实验的“实验提交系统”却是一个扣分项,分明有更好的ide可以使用但是却不让用,甚至还给复制粘贴锁了,一些重复的且必要的代码又要自己一个一个敲上去太折磨了,主要在那里面编写代码时既没有报错也看不见行数,修改错误时要花费大量的时间去一点一点的找,只能说输入错误的代价太高了导致了写着写着就想放弃,也因为这个实验提交系统必须要用校园网才能登陆导致我在端午回家时还不能写实验作业。

博客作业相关:

博客作业次数不多,主要为一个总结性的作业,让我们总结自己在这次大作业中的错误以及收获,我认为这个还是很好的,能让我们及时的捡起掌握的知识点也能及时的反思在上一次作业中的不足之处。


第一次电梯大作业:

要求: 设计一个电梯类,具体包含电梯的最大楼层数、最小楼层数(默认为1层)当前楼层、运行方向、运行状态,以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列,其中,电梯外部请求队列需要区分上行和下行。
电梯运行规则如下:电梯默认停留在1层,状态为静止,当有乘客对电梯发起请求时(各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮),电梯开始移动,当电梯向某个方向移动时,优先处理同方向的请求,当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时,如果有新的请求,就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时,检查当前是否有请求(访问电梯内请求队列和电梯外请求队列),然后据此决定移动方向。-每次移动一个楼层,检查是否有需要停靠的请求,如果有,则开门,处理该楼层的请求,然后关门继续移动。
对于这次的大作业,我的准备并不充足,实话说我没有规划好自己的编写代码的流程导致我没有完成这次的作业
image
显而易见我的代码问题很多,在平均复杂度,最大复杂度方面尤为突出,我的代码复用非常的少,第一次进行编写时没有整合同一种类的操作到一个类里导致代码过于复杂和可读性很差还导致维护和更新迭代十分困难;


第二次大作业:
要求:
某航空公司“航空货运管理系统”中的空运费的计算涉及多个因素,通常包括货物重量/体积、运输距离、附加费用、货物类型、客户类型以及市场供需等。
本次题目模拟某客户到该航空公司办理一次货运业务的过程:
航空公司提供如下信息:
航班信息(航班号,航班起飞机场所在城市,航班降落机场所在城市,航班日期,航班最大载重量)
客户填写货运订单并进行支付,需要提供如下信息:
客户信息(姓名,电话号码等)
货物信息(货物名称,货物包装长、宽、高尺寸,货物重量等)
运送信息(发件人姓名、电话、地址,收件人姓名、电话、地址,所选航班号,订单日期)
支付方式(支付宝支付、微信支付)
在这次的大作业中我的编程速度和质量可以说比第一次要好上不少,第一次大作业中我的许多错误在这次的大作业中也没有再现,
image
虽然这次作业我的SourceMonitor分析后发现有些数据分析不出来但是就我的感觉来说应该是比第一次要好的,但是问题也依旧存在,在对代码进行编写时我也同样的发现我对一些基础知识的运用并不娴熟,注释太少了交给其他人的话可能会浪费时间在识别我的代码的作用上,在NormalGood、DangerousGood、ExpediteGood三个货物子类的编写上有很大的问题,为了方便我根本没有用上这三个子类而是直接去用字符识别


对实验的总结:
在第五次的实验中首次要求我们使用javafx去为原本的动物与电器的代码构建一个图形界面,在编写这次的实验中我也发现我对于javafx方面的只是与技术的掌握还有所欠缺,我其实都没搞明白它到底是干啥的。就知道是 Java 用来做界面的东西,具体的架构和核心组件,完全是一头雾水。结果写代码的时候就出大问题,比如布局管理器,BorderPane、VBox 这些东西,我根本不懂它们的原理,随便写一通,最后界面上的按钮、文本框全乱套了,根本不是我想要的样子。还有事件处理,按钮点击该怎么响应,我连事件监听器怎么绑定都不清楚,写出来的功能根本没法用,点了按钮跟没点一样。而且我学习的时候特别没章法,看到哪个案例有意思就去试哪个,从来没想过从简单的界面开始,一步一步慢慢来。结果学了一堆零散的东西,好像啥都会一点,但真要自己做个完整的项目,又完全不知道从哪下手。平时我也不爱翻官方文档,也不去看别人写的好项目,所以错过了好多能把代码写得又简洁又高效的技巧,自己写的代码乱七八糟,一点都不规范。还有就是,我总觉得 JavaFX 是独立的,没把它和 Java 的基础知识联系起来。后来才发现,JavaFX 运行的时候,很多地方都要用到 Java 的面向对象和多线程这些知识。我 Java 基础本来就不扎实,遇到复杂一点的业务逻辑,直接就懵了,感觉自己学的东西完全不够用。


现在我通过pta的训练以及实验代码的编写,对java的掌握程度更高了一些,我现在应该是已经掌握了简单的继承,多态,接口等内容的运用,我在接触到了javafx之后我有种冲动就是把之前自己写的面向对象的代码都用javafx写出一个界面用于使用但现在我对javafx的了解还是停留在表面的程度,在之后的学习中我会努力将这些变为可能


关于异常处理学习的反思

在学习异常处理的过程中,我逐渐认识到它在程序开发中的重要性。异常就像是程序运行时的 "小插曲",可能是文件找不到、网络连接中断,或者是用户输入了错误的数据。我掌握了异常处理的基本结构,知道可以用 try-catch-finally 块来 "拦截" 这些 "小插曲"。try 块就像是一个 "安检区",里面放着可能会出错的代码;catch 块则像是 "问题处理中心",可以针对不同类型的异常采取不同的处理措施;finally 块更像是一个 "收尾工作区",不管有没有异常发生,里面的代码都会执行,比如关闭文件、释放资源等。

目前,我已经能够运用基本的异常处理语法来应对一些常见的问题。当编写需要读取文件或者进行网络操作的代码时,我会很自然地想到添加异常处理,就像给程序穿上了一件 "防弹衣",让它更加健壮。

然而,我也清楚自己在异常处理方面还有很多需要学习的地方。比如,对于自定义异常,我还只是一知半解。虽然知道可以创建继承自 Exception 或 RuntimeException 的类来定义自己的异常类型,但对于在什么场景下需要自定义异常,还没有很清晰的认识。另外,在异常的传递和捕获更具体的异常类型方面,我还需要更多的实践。有时候,我会捕获一个很宽泛的异常类型,这样虽然能解决问题,但可能会掩盖一些潜在的问题。还有,在合理使用 finally 块以及如何设计友好的用户错误提示方面,我也还有很大的提升空间。有时候,我会对哪些异常需要捕获、哪些可以通过代码逻辑避免判断不准确,导致代码中要么添加了过多不必要的异常处理,要么遗漏了一些重要的异常情况。


踩坑心得:

在这个学期对于java得学习得过程中,我发现在编写代码之前一定要优先得在大脑中规划出这次代码得框架以及弄清楚父类以及接口,提前准备这些相关的方法才能更加高效的完成作业在设计继承关系时应在最大限度内将复用的变量和方法都编写进父类中以减少后期的工作量;
当设计的类中存在多个不同的作用但是大体相同的方法时还是要使用父类然后重写相关代码,这样在结构上更加清晰正确
在设计类的继承关系时,要充分考虑每个子类的独特职责。不能让子类的作用重叠,没有真正发挥继承的优势。在设计类继承关系前,一定要深入分析每个类的核心职责,确保子类能够清晰地扩展父类功能,遵循单一职责原则,避免出现类功能混乱的情况。
编写代码时将功能相同或相似的方法整合在一起。


改进建议以及总结:

总的来说这些作业让我收获颇丰,但是我还是希望把实验提交系统的复制粘贴搞回来,或者干脆直接用ide进行实验的代码的编写,因为现在的实验提交系统确实不如ide的好用,要寻找错误还得自己去把代码复制到ide里后找错误然后再切屏回来之后去自己找,这个效率确实很低而且打击信心,感觉要反作弊可以用别的方法而不是这个比较极端的方法。但是其他的地方否是非常好的,也希望我能在编程这条路上越走越远。

posted on 2025-06-16 23:41  微光红茶  阅读(11)  评论(0)    收藏  举报

导航