电梯题总结
前言：
- 这三次的题目不算特别难，主要的难点是电梯的运行逻辑，一旦想通了这点，这题就没有那么难了。除了这个，还有就是怎么实现比较麻烦了。
- 题目的量不算太太，只要第一次的题目做出来了，后面的题目做起来就很快了。
- 通过这三次的题目学到了很多：
- 如何根据需求设计程序
- 熟悉了Java的基本语法
- 认识到了什么是面向对象
设计与分析：
第一次题目：
SourceMonitor分析报表：
PowerDesigner类图：
分析：
- 共 184 行，语句 132 条 ，规模适中。有 2 个类或接口，结构不算复杂，但也具备一定规模
- 46 条方法调用语句，说明代码中不同功能模块间交互较为频繁，功能划分有一定颗粒度
- 分支语句占比 24.2% ，意味着代码中存在不少条件判断逻辑，业务逻辑有一定复杂性
- 含注释行仅占 1.6% ，注释过少
- 从图表看，代码在不同深度有语句分布，存在一定嵌套结构；雷达图能辅助查看平均复杂度、最大深度等指标，可进一步剖析代码逻辑复杂程度
第二次题目：
PowerDesigner类图：
分析：
（1）305 行，209 条语句，规模适中
（2）分支语句占 16.7%，有条件逻辑；107 条方法调用语句，交互频繁
（3）涉及 6 个类或接口，有一定模块化
（4）雷达图显示部分复杂度、深度指标不佳；柱状图表明有较多嵌套结构。 代码需优化提升可读性和可维护性
（5）注释行仅 0.3%，几乎无注释，不利阅读维护
心得体会：
这三次的代码的分支语句占比普遍偏高，并且方法调用语句也较多，交互频繁。代码缺少注释。雷达图显示部分复杂度、深度指标不佳，代码需优化提升可读性和可维护性。通过这三次的代码分析，我会加强我的代码编写能力，注意标注注释，减少代码分支，嵌套等。
第三次题目：
SourceMonitor分析报表：
PowerDesigner类图：
分析：
（1）330 行，代码量不算极少，有一定规模
（2）16.9% ，意味着约六分之一的语句是分支语句，说明代码中有一定的条件判断逻辑，但比例不算特别高，代码逻辑没有过度复杂
（3）表明代码中频繁进行方法调用，这是比较常见的代码组织方式，通过方法调用来实现模块化和复用
（4）雷达图指标：反映代码在复杂度、深度、方法数量等多方面状况，部分指标欠佳
心得体会：
- 代码注释的完整性有待加强，应该增加必要的注释说明，以提升代码的可读性与可维护性
- 代码分支结构需优化，过多分支可能导致逻辑复杂度上升
- 应合理控制代码模块间的调用关系，减少不必要的依赖，进一步降低程序耦合度
- 当前代码在算法设计与结构组织上仍有提升空间
采坑心得：
这三次作业我踩的最主要的坑就是第一次作业的时候，这也导致我的第一次作业并没有按时完成（而且第一次作业花费的时间最长，真的做了很久），我是后面才完成的。最初我没有理解电梯是怎么运行的，我试过很多种运行方式。事实告诉我没有按照老师的需求做，就是浪费时间。后来我根据老师提供的测试用例（补充）搞清楚了如何判断电梯是否需要改变方向，如何判断电梯是否要停止，如何寻找下一目标楼层。这样我才解决了第一道难题。这个惨痛的教训教会了我一定要根据需求设计。
第二个难题就是如何实现寻找最近楼层，判断电梯是否需要改变方向，判断电梯是否要停止。我在这上面花费的时间也不少。我一直在先判断方向，还是先判断最近楼层里徘徊。但是我两个方式都有尝试过，好像都无法得到正确的结果。我不确定是我判断是否改变方向的思路出现了问题还是寻找最近楼层的思路出现了错误。这个地方卡了我很久。我迫不得已，最后只好将两个过程融合一下。
上面的问题虽然解决了，但是这样的作法又产生了另一个问题。两个步骤融合在一起，导致我的代码需要用很多分支来判断不同的情况。在解决这个问题过程十分容易出错，一出错就要花费大量时间调试。这样的做法还使后面的迭代问题更加复杂，使得代码量增大，并且大大降低了代码的可读性。这次踩坑也给我一个教训，要遵守SRP单一职责原则，做到每个方法的职责单一。
后两次的题目涉及分解类。我在这个方面的主要问题是因为前面造成的代码量增大，代码的可修改性不强，使得我需要修改的地方增多。我在这个地方也踩了重复调用的坑，导致我的代码十分冗余，显得代码十分混乱。这个地方我认为是最需要注意的，一个代码需要考虑它的可维护性，这样可以大大减少将来维护的工作量。此外，我也需要减少代码的重复调用，使得代码更加简洁，提高代码的可读性。
改进建议：
代码问题分析：
第一次题目并未要求我们严格的按照面向对象原则来做，主要是为了给后面的问题打基础，了解电梯的运行过程。我的第一次题目的代码中Elevator类中有关电梯运动的方法只有findNearestRequest()，changeDirection()， move()。这就会造成很多问题。后面两次题目的代码同样有上述情况，除此之外，以为加上了类的分解，在类的处理方面也存在一些问题。
- 现有代码中，核心功能集中在findNearestRequest()等少数几个方法内，导致单个方法代码行数过多。
- 从面向对象设计角度看，现有方法违反了 [单一职责原则（SRP）]，一个方法承担了多个独立的功能。例如， “findNearestRequest()“方法既负责寻找最近楼层，又执行判断是否改变电梯运行方向功能。这种设计导致方法之间的依赖关系不清晰，增加了代码的复杂性和出错概率。
- Controller类的move()方法复杂度高
该方法包含电梯运行的核心逻辑（方向判断、楼层移动、开关门控制），同时调用findNearestRequest()和循环处理楼层移动，代码行数超过 200 行，违反 “单一方法只做一件事” 的原则。
改进建议与优化方向：
- 按功能边界拆分将原方法中独立的逻辑块提取为更小的方法，例如：
- 寻找最近楼层逻辑：封装为findNearestRequest()方法，专门负责寻找下一请求离当前楼层最近的楼层
- 判断是否改变方向逻辑：分离为checkWhetherChangeDirect()方法，专门负责判断并改变电梯的运行方向
- 控制方法复杂度遵循“方法行数不超过100行的原则，确保每个方法的功能一目了然。对于超过阈值的方法，进一步拆解为更小的子步骤
- 拆分Controller类的move()方法：
- 将楼层增减和状态输出封装为moveOneFloor()方法
- 提取请求处理逻辑：将请求队列的筛选、方向调整、请求转移（外部请求转内部）拆分为独立方法
总结：
学到了什么：
通过这三次题目，我学到了很多：
- 首先就是程序设计一定要根据客户的实际需求设计。
- 了解了面向对象语言的基本设计原则。
- 单一职责原则（SRP）的实践感悟：通过本次开发，深刻体会到 “一个类 或者方法只负责一项职责”的重要性。
- 认识到了提前规划类职责的重要性。
需要加强的地方：
- 先完善代码健壮性和工程化规范（代码格式、注释），确保代码的稳定性和可维护性；
- 学习并应用设计模式，提升代码的扩展性和可复用性；
- 学习并应用Java语言的设计原则，如单一职责原则，里氏代换原则，迪米特法则等等，提高代码的质量
心得体会：
三次电梯题的开发历程，是从 “功能实现” 到 “质量优先” 的认知跃迁。我体会到：优秀的代码不是一次性写成的，而是通过持续重构演进而来，我也深刻的认识到了自己的不足。若想成为一名合格的程序员，需以更勤勉的态度弥补能力短板。实践是知识转化的核心环节，未来我需要多将理论知识付诸实践，将老师讲的知识变成我自己的知识。
编程本质是将现实问题抽象为计算机可执行逻辑的过程，而面向对象设计正是连接问题域与解决方案的桥梁。通过本次实践，我不仅掌握了电梯调度的技术实现，更重要的是建立了 “用设计原则指导编码” 的思维范式，这将成为未来应对复杂系统开发的核心能力。
对该课程的建议：
通过本课程的学习，我的 Java 面向对象程序设计能力得到了有效提升。在此，我想提出一些个人的建议，希望程序设计课程可以越来越好。
我个人觉得我的Java设计原则的实际运用能力比较欠缺。虽然老师确实在着重教授设计原则这方面的知识，但是我认为还是缺少实际的练习。这几次的题目我学习到了SRP单一职责原则，我希望后面的练习可以涉及更多的Java设计原则方面的知识。
浙公网安备 33010602011771号