第一次blog作业

1.前言

 刚接触面向对象程序设计和开始学习Java编程语言的时候，确实觉得所有的一切都很困难，所有的一切都很陌生。面对全新的概念和编程方式，感觉自己像是进入了一个完全陌生的领域，需要从头开始探索。那时候，连最基本的类和对象的概念都理解得不够透彻，编写一段简单的代码也显得笨手笨脚。不过，随着课堂上的学习一步步深入，老师详细地讲解了面向对象的核心思想和Java的基本语法，我逐渐对这些陌生的概念有了一些初步的认识。慢慢地，我能看懂一些简单的代码。接着，通过在PTA平台上完成一道道题目，我对Java编程的掌握越来越熟练。这些题目由浅入深，让我在实践中巩固了所学的知识。每当完成一道题，就感觉自己又进步了一点，对编程的信心也增加了一些。在这个过程中，我发现编程其实也没那么难，只要认真思考，细心调试，很多问题都能迎刃而解。然而，当遇到电梯大题时，我意识到自己之前的认知有多么片面。面对复杂的电梯调度逻辑，我突然发现自己所学的知识只是冰山一角。如何设计合理的类结构，如何处理各种边界条件，如何让电梯的运行高效而合理，这些问题都让我感到无从下手。

 

 题目集 5 ：包括了如求身份证号校验位、求解一元二次方程、正则表达式训练 - 验证码校验、正则表达式训练 - QQ 号校验以及单部电梯调度程序等五道题目。整体而言，题量适中，前四道题目的难度相对较低。面对这些题目，只要投入足够的时间和精力，便能够顺利解决。然而，对于我而言，第一次接触到 Java 大题时，感到十分茫然，不知从何处下手，这凸显了我在编程实践方面的经验不足，也让我意识到自己需要在复杂问题的解决思路上多下功夫。

 

 题目集 6 ：涵盖了点与线（类设计）、汽车风挡玻璃雨刷问题（类设计）、单部电梯调度程序（类设计）这三道题目，此次题目集将重点放在了类的设计上。最初接触类设计时，我有些不知所措，头脑中一片混乱，对如何合理地设计类的结构、属性和方法没有清晰的概念。但随着我对相关知识的深入学习和理解，耐心地去分析每个类所代表的现实对象以及它们之间的关系，我逐渐发现类设计也并非想象中那般高不可攀。不过，在面对单部电梯调度程序这道题时，尽管我努力思考，却仍未找到合适的解决方法，这让我明白在类设计的实际应用中，还需要更多的实践和探索。

 

 题目集 7 ：包含销售步枪问题、蒙特卡罗方法求圆周率以及单部电梯调度程序（类设计 - 迭代）这三道题目。相较于前两次题目集，本次题目集的难度有了显著提升。虽然题量有所减少，但每一道题目都更具挑战性。在每天的晚自习时间里，我全身心地投入到对这些题目的思考和尝试中。起初，面对复杂的题目要求，我感到有些无从下手，但随着时间的推移，我逐渐熟悉了题目所涉及的知识点和逻辑结构，慢慢理清了解题思路，最终成功完成了前两道题。然而，由于时间有限，对于最后的单部电梯调度程序（类设计 - 迭代）这道题，我不得不遗憾地放弃，这让我深刻体会到在面对难度较大的编程任务时，合理的时间管理和任务规划是多么重要，同时也让我更加坚定了不断提升自己编程能力的决心。

2.设计与分析

1.题目集5单部电梯调度程序

（下面是SourceMontor的生成报表内容）



代码行数是 184 行，包含了 128 条语句和 73 次方法调用，分支语句占了 26.6%，平均每方法语句数大约是 9.91 条，这让我意识到代码有一定的复杂度，但整体还算可管理。不过，注释行占比只有 1.6%，这明显是不够的，我应该在代码中添加更多注释，以便日后维护和他人阅读。代码中定义了一个类，包含 11 个方法，最深嵌套块深度是 4，出现在第 164 行，这提示我在某些地方可能写了一些比较深的嵌套逻辑，未来可能需要重构以降低复杂度。

 

 

以下是我对第一次电梯调度程序代码的分析、踩坑心得和改进建议：

(1)好处:

这段代码里的 Main 类，就是电梯调度的 “大脑”，一心一意就管电梯的运行操控和各种请求处理。它靠维护着内部的请求队列，还有外部的上行、下行请求队列，就能把不同类型的请求给合理地应对了，电梯到底是往上跑、往下跑，还是停着，也都能按照既定规则安排得明明白白，从而把电梯的运行流程给模拟出来。而且，对电梯的那些状态，像到底是停着、在移动，还是开门、关门，以及方向，是往上、往下还是不挪动，都管理得清清楚楚，电梯就能依据当前的状况和收到的请求，做出恰当的行动决定啦。总的来说，这代码在电梯调度那些基本活儿上干得不错，但是，类的结构上还能再优化优化，代码的可维护性也有提升的空间，让它后续改进起来更方便些。

(2)不足:

该代码存在封装不足的问题，电梯相关属性和方法可进一步封装至独立的Elevator类，避免逻辑过度集中于Main类，当时也没想那么多，就全写在Main类里面了，后面才知道这样太麻烦了，也不便于修改。同时，其错误处理机制不够完善，对边界情况和非法输入的处理存在欠缺。此外，当前调度算法较为简单，未采用更高效的电梯调度算法进行优化。

(3)踩坑心得:

这段代码存在多处设计缺陷。首先，类设计不合理，电梯相关逻辑未封装成独立类，致Main类职责过多，代码可读性和可维护性变差，真的非常不便于修改，一定不要把所有代码全放在Main类里面。其次，请求队列管理复杂，处理多个请求队列时逻辑易复杂化，判断电梯运行方向和处理请求时易出现遗漏或错误。然后，状态转换混乱，电梯状态和方向管理不清晰，状态转换时易出现逻辑错误，测试时老是出现各种错误，总会漏掉一些本该输出的东西。

(4)改进建议:

为了使电梯调度程序更加完善，可以考虑以下几点优化措施。首先，将电梯的相关逻辑重构并封装到一个独立的Elevator类中，并创建一个Request类来更好地管理请求。这样可以提高代码的可读性和可维护性。其次，优化方法的命名，使其更具描述性，并在必要时添加注释，以便更好地解释方法的功能和逻辑。此外，增强错误处理机制，确保程序在面对非法输入和边界情况时能够更加稳定地运行。同时，改进调度算法，例如采用更高效的集体调度算法，以提升电梯的运行效率。

(5)总结:

总的来说，这次单部电梯调度程序是我学习面向对象程序设计以来，碰到的第一个大难题，有很多地方都无从下手，还是跟同学老师讨论，才一步步完成自己的代码，虽然仍然有很多地方有缺陷，但是我已经尽力去完成了。在这个过程中，我不断地调整思路，重构代码，优化算法，尽管仍然存在很多缺陷和不足，但我已经尽我所能去完成每一个细节，去修复每一个漏洞。虽然最后程序还是未能完全通过所有的测试点，但当我回顾整个过程时，内心依然充满了满足感。同时我也认识到自己的不足，在面对难题时的无从下手和胆怯，都是我需要努力克服的困难。在今后的学习和实践中，我将会更加努力学习新的知识并积极运用到实践中。

2.题目集6单部电梯调度程序（类设计）

（下面是SourceMontor的生成报表内容）



在对 Main.java 文件进行代码度量分析时，我发现这份报告揭示了代码的一些关键特性。代码行数达到了 271 行，其中包含 144 条语句和 51 次方法调用，这表明代码具有一定的复杂度。分支语句占比 13.9%，显示代码中存在条件逻辑，而平均每方法语句数为 4.42 条，提示方法的复杂度相对较低。注释行占比 6.6%，虽然比理想情况稍低，但至少提供了一些基本的注释。代码定义了 4 个类或接口，每个类平均拥有 7.75 个方法。最复杂的函数是 Main.main()，其复杂度达到了 7，位于第 226 行。最深的嵌套块深度为 5，出现在第 247 行。

 

 

以下是我对第二次电梯调度程序代码的分析、踩坑心得和改进建议：

(1)好处:

此次电梯调度程序代码我采用了面向对象的编程思想，将电梯、乘客请求、请求队列和电梯控制器等功能模块封装成独立的类，每个类职责明确，不仅提高了代码的可读性，还增强了可维护性。通过定义 Elevator、PassengerRequest、RequestQueue 和 ElevatorController 等类，形成了完整的类层次结构，清晰地展现了系统各部分的关系和交互。此外，面向对象的设计使得系统在应对需求变化时具有良好的适应性，例如可以通过继承 Elevator 类创建特性各异的电梯子类，或扩展 PassengerRequest 类以支持更多类型的请求。

(2)不足:

代码中的电梯调度逻辑相对基础，未采用更高效的调度算法，可能导致电梯运行效率不高，尤其在处理复杂请求时无法实现最优调度。错误处理机制不够完善，尤其是对非法输入和异常情况的处理存在欠缺，例如未对乘客请求的格式进行严格验证，可能导致程序运行时出现异常。此外，代码缺乏详细的日志记录功能，虽有部分打印输出，但在调试和监控电梯运行状态时，提供的信息不足以帮助开发者快速定位问题。

(3)踩坑心得:

电梯调度逻辑复杂，涉及多个请求处理和电梯状态转换，在实现过程中容易出现逻辑错误或遗漏某些情况，需要仔细分析和全面测试。输入验证至关重要，不合理的输入可能导致程序崩溃或行为异常，因此必须对输入进行严格验证和处理，以确保程序的健壮性。调度算法的选择需平衡简单性和效率，简单的逻辑可能无法满足复杂实际需求，需深入研究并实现更高效的调度算法。

(4)改进建议:

为优化电梯调度程序，我认为可从调度算法、错误处理、日志记录、用户界面、代码结构和注释等方面入手。首先，研究并实现更高效的调度算法，如集体调度算法或基于时间的调度算法，以提升电梯运行效率和响应速度。其次，增强错误处理机制，完善对非法输入和边界情况的处理，增加异常捕获和错误提示，确保程序在异常情况下稳定运行。同时，添加详细的日志记录功能，记录电梯运行状态和请求处理过程，便于调试和监控。此外，改进用户界面，提供命令行参数解析、输入提示和菜单引导等，以提升用户体验。最后，进一步优化代码结构，提高可读性和可维护性，并增加注释以解释关键逻辑和算法，便于其他开发者理解和维护代码。

(5)总结:

总的来说，此次单部电梯调度程序（类设计）衔接了上一次单部电梯调度程序，但是此次更加注重于类的设计和使用，刚好可以解决我上次电梯题目类使用过少的问题，可以更好的解决代码更改不方便的问题，但是此次电梯题目也有自己的难点，Elevator 类和 RequestQueue 类之间的交互有些混乱，导致我在这个地方卡了很久，一直搞不清楚之间的关系。

3.题目集7单部电梯调度程序（类设计 - 迭代）

（下面是SourceMontor的生成报表内容）



这份报告对 Main.java 文件进行了代码度量分析，提供了多个关键指标。代码行数为 224 行，包含 128 条语句和 59 次方法调用，分支语句占 10.9%，平均每方法语句数为 3.00 条。注释行占比为 0.0%，表明代码缺乏注释，这会降低代码的可读性和可维护性。代码定义了 7 个类或接口，每个类平均包含 3.86 个方法。最复杂的函数是 Controller.scheduleElevator()，其复杂度为 9，位于第 156 行。最深的嵌套块深度为 5，出现在第 211 行。

 

 

以下是我对第三次电梯调度程序代码的分析、踩坑心得和改进建议：

(1)好处:

这段电梯程序，就是把电梯、乘客、请求队列和控制器这些东西，都打包成一个个独立的小模块来处理，这样代码看起来更清楚，以后想要改改这儿、动动那儿的也方便不少。像电梯到底是往上跑、往下跑还是停着，门是开着、关着还是在动，这些状态和方向都用枚举类的方式列个清单，用的时候直接拿，既不容易错，看着也明白。然后程序里写了基本的电梯调度规则，比如乘客一按按钮，控制器就能收到信号，指挥电梯过去，到了地方开门让人上下，完了再关门接着跑。

(2)不足:

调度算法较为基础，未采用更高效的调度逻辑，可能导致电梯在处理复杂请求时效率不高。其次，错误处理机制不够完善，对非法输入和异常情况的处理存在欠缺，例如未对乘客请求的格式进行严格验证，可能会导致程序在运行过程中出现异常。此外，代码中的注释较少，影响了可读性和可维护性。最后，日志记录功能不完善，调试和监控电梯运行状态时，可能无法提供足够的信息来帮助开发者快速定位问题。

(3)踩坑心得:

在实现电梯调度程序的过程中，我深刻认识到面向对象编程的强大之处，通过合理的设计类和对象，可以清晰地模拟现实世界中的复杂系统。但也遇到了不少挑战，尤其是在处理多个乘客请求和电梯状态转换时，逻辑容易变得复杂，需要仔细分析和全面测试以避免错误。此外，调度算法的选择对程序性能有着重要影响，简单的调度逻辑可能无法满足复杂的实际需求。

(4)改进建议:

为了优化这段电梯调度程序代码，可以从以下几个方面入手：首先，优化调度算法以提高电梯的运行效率，例如采用更高效的调度算法来处理多个请求。其次，增强错误处理机制，增加对非法输入和异常情况的处理，确保程序的健壮性。此外，添加详细的注释和文档，解释代码的逻辑和算法，提高代码的可读性和可维护性。

(5)总结:

最后一次单部电梯调度程序（类设计 - 迭代）搞得我有点力不从心了，由于上一次电梯大题未完全通过所有测试点，所以无法从上一次代码的基础上来写这一次电梯大题，又加上大学生英语竞赛和英语期中考试，我需要分更多的时间和精力到英语的学习上，所以这一次在尝试了几次后，花费了3天晚上后就放弃了。我也很无能为力，自己并不是对java编程语言有很深的理解，所以编写代码的速度并不快，再加上没有写注解的习惯，所以就经常导致看了上面忘了下面，在此次电梯大题后，我懂了自己在遇到难题时的困窘，所以在今后的学习中要加倍努力。

3.踩坑心得

 目前的代码虽能实现电梯调度功能，但部分方法未被充分利用，一些方法逻辑重复且繁琐，可拆分为多个方法，以提高代码可读性和便于后续维护。在可能越界的地方加入判断，利用 try-catch 语句捕获异常，能更好地检测问题所在，快速定位并解决问题。此外，编写可复用的优质代码，避免重复计算，有助于提升程序运行效率。最后，代码的注释较少，尤其是复杂逻辑部分，应在关键代码段、方法定义和变量声明处添加详细注释，注明每个方法的功能及参数含义，否则过段时间自己都可能忘记代码逻辑，从而降低效率。未完成读懂题目的意思就开始做题，导致自己敲了半天的代码，白打了。

4.改进建议

 在这次三道电梯大题中，我发现自己有许多地方需要改进：首先就是注释太少了（主要是没有习惯去打注释，也是有些地方没有完全理解就使用了），这严重影响了代码的可读性和可维护性，因此在关键方法、复杂逻辑块和类定义处添加详细注释在后续编写代码时，我会在关键的分支点添加更多注释，详细说明代码逻辑，这样无论是自己回顾代码，还是他人阅读代码，都能更加顺畅。然后就是部分方法的复杂度居高不下。这反映出我目前仅仅满足于达成题目的目标，却忽略了代码至关重要的可维护性和健壮性。通过静态分析，我还发现一些方法的调用次数过多，这表明代码的耦合度较高。接下来，我会采用各种有效的方法对代码进行优化，以降低方法之间的耦合度。然后就是有很多代码在设计之初认为它们有自己的作用，但是在编写代码的过程中，慢慢地察觉它们并没有任何作用，但是最后还是保留了，这无疑使得我的代码更加复杂，更难读懂，在此后的作业中，我会仔细检查每行代码的作用，然后判断是否需要修改或删除。最后，我对学习java的工具开发程度太低了，过度依赖于老师发布作业的PTA，这也导致于在空闲时候，自己写一些小项目时，不知道使用什么工具，在此后，我会更加熟悉地使用学习java的工具，例如IDEA等。

5.总结

 1.这三次电梯大题给了我一拳，我真正认识到学习面向对象程序设计的路还长着呢，一道题要花了几天的时间才能一步步完成，中途可能还会碰到一些自己无法跨过去的鸿沟，所以在今后的学习中，只有更加努力，才能跟上学校的进度，完成自己的任务。

 2.历经这三次作业的迭代式开发，我对 Java 基础语法已经十分了解。虽然了解，但是运用到实际中，任然有困难，所以我需要自己多多动手去编写代码，才能将理论应用到实际中。

 3.我要跟紧老师上课的步伐，积极与老师讨论相关问题的解决方法，学习面向对象程学设计的基本原则，才能在再次面对像这次电梯难题时不再无从下手，才能有自信去完成它，而不再是辛辛苦苦编写了好几天的代码，最后却过不了测试点。