第一次blog作业

一、前言

其实还没等我从c语言的学习里反应过来，我就迈向了Java学习的大门，然而刚进入Java学习时候，我并不习惯，因为感觉到Java程序的编写比c语言更加的繁琐复杂，因为感觉c语言只需要把各个定义写清楚就好了，而面向程序设计包含了一个程序的打开和关闭等等苛刻复制的条件（对于我来说），相比前四次题目集后面5、6、7三次题目集的难度完全上升了一个层次，这次的题目主要采用6+3+3的方式，除去三道电梯类题目剩下的八道题目。我觉得主要分为三个方面，主要分为几何计算，应用于逻辑业务的算法和关于正则表达式的应用。通过这些题目的反复练习，也让我大概摸清了Java的入门方向。当然这里面最具有挑战性，最锻炼人的编程水平和让能力提升的还是这三道电梯题目，然而本身Java基础薄弱的和c语言学的并不牢固的我，在算法能力和编程逻辑思维上并不强势，所以导致我这三道题不能很好的完成，只略懂了一些皮毛，都不能在截止的时间内完成，这是我的一大遗憾，但是在今后的学习中，我还是会坚持把这三道题目弄懂为止，下面我来分析一下我对这三道题目的了解和学习心得。

二、具体分析

1. 关于第一道电梯类题目也是最简单的一道，也是卡了我其实时间最久了一道，问题一开始就出现在输入问题上，我没有检查输入的楼层是否在min和max范围内。
   

// 错误代码 int floor = Integer.parseInt(parts[0]); if(parts[1].equals("UP")) outsideUp.add(floor);
而后我很快做出了改正
int floor = Integer.parseInt(parts[0]); if(floor >= min && floor <= max) { if(parts[1].equals("UP")) outsideUp.add(floor); }
通过这个代码我能处理好边界条件了，当然这只是我刚开始入门没考虑全的问题中的一个例子，然后算法逻辑上我最大的一个缺陷就是不能很好的模拟电梯的运行。导致电梯每经过一个指定楼层，没有删除当层停下来，而是继续运行。我需要通过添加更严格的方向检查逻辑解决了这个问题。

可以看出我的输出非零返回，下面让我们测试一下

1.1代码行数：67 行，属于小型文件，但结合其他指标显示功能集中度较高，可能存在功能模块化不足的问题。
1.2有效语句数：53 句，语句密度达 79%，代码过度紧凑，可能导致可读性和维护性下降，需注意代码换行与逻辑分隔。
1.3分支语句占比：32.1%，高于推荐的 15%-25% 范围，控制流逻辑较为复杂，可能增加代码理解难度和调试成本。
1.4方法调用语句：44 次，平均每行代码调用 0.66 次方法，反映方法间耦合度较高，模块独立性差，不利于代码扩展和复用。
1.5类 / 接口数：1 个，违反 “单一职责原则”，所有功能集中在一个类中，不符合面向对象设计规范，代码可维护性和可测试性较差。
1.6方法数 / 类：1 个，呈现典型的 “上帝方法” 反模式（逻辑集中在main()方法中），方法承担过多职责，导致代码结构混乱，难以拆分和优化。
1.7方法平均语句数：48 句，严重超过推荐值（≤20 句），方法体过于臃肿，应拆分为更小的子方法，以提高代码可读性和可维护性。

然而尽管我try my best依然无法解决这个问题，我的楼层切换逻辑很混乱，老是会跳个楼层，我的检查条件被忽视了，而且相同的请求也会导致我的程序输入无效，输入的混乱情况，导致电梯的运行方向不能确定。且根据图片可以看出我的函数尽量用的都是最基础的函数语句，然后复杂度也比较低，使用了大量累赘的if/while语句。感觉还是算法上的缺陷。根据以上结果，可以看出我的程序显得有点臃肿了，这也是我觉得Java又臭又长的原因。

2.第二道电梯比起第一道更复杂了，对于我这个第一道还纠缠不清的人更是折磨了，根据老师的设计类图提示需要拆分为：Elevator（状态）、Request（数据）、RequestQueue（管理）、Controller（调度）。

对于多于的外部请求，我不能和电梯内部运行很好的调配，我想这是基于外部请求和内部电梯连续运行上的算法逻辑冲突，我直接使用的是List储存而非set并未能正确的使用equals（）

可以看到我的电梯是缝层必停（哭），可以看出类设计虽然看似条例清晰了很多，实际上更考验我们的调度和全局能力了，然后以下是我的实验代码用SouceMonitor分析的结果：

2.1代码行数：80 行，相较于小型文件规模有所增加，功能可能进一步扩展，但也需警惕功能过度集中或模块化不足的问题持续存在。
2.2有效语句数：53 句，语句密度较高，虽未发生变化，但仍需关注代码紧凑带来的可读性和维护性挑战，注意合理的代码换行与逻辑分隔。
2.3分支语句占比：20.8%，处于推荐的 15% - 25% 范围，控制流逻辑复杂度较为合理，有利于降低代码理解难度和调试成本。
2.4方法调用语句：23 次，相较于之前有明显减少，方法间耦合度有所降低，模块独立性增强，利于代码的扩展和复用。
2.5类 / 接口数：3 个，一定程度上遵循了 “单一职责原则”，功能拆分更合理，符合面向对象设计规范，提升了代码的可维护性和可测试性。
2.6方法数 / 类：1.67 个，低于小型类推荐的 3 - 5 个方法，可能存在类职责划分过细或方法拆分不充分的情况，需要进一步优化以提高内聚性。
2.7方法平均语句数：7.6 句，方法体简洁，符合 “单一职责” 原则，代码可读性和可维护性良好。

根据结果可以看出，我的功能进一步扩展，虽然只是在题一的基础上稍加改动，但是我还是得到了许多进步，比如至少可以让电梯运行了。但仍然存在代码臃肿的问题，语句简单重复，算法单一。

3.第三道电梯作为压轴BOSS出场，在原基础上引入了乘客类，要求我们能够进行请求语义转换、动态路径规划、多类协作等等

根据以上类图可以明确知道需要我们做到枚举类型，封装乘客的乘梯请求等等，核心难点在于Controller中的调度算法实现（如同方向优先、请求合并等），这对于我无异于雪上加霜，我新增Passenger类，与RequestQueue的交互更复杂，代码更加复杂，一度出现超时运行现象

我冗长的代码使得相似的功能在不同地方重复实现，缺乏抽象。而且基于我薄弱的算法，我还是只能尝试从简单的请求运行写起，以下是我的代码分析：

可以看出
3.1代码行数（Lines）：105 行，规模适中，不过具体是否存在功能模块化不足等问题，还需结合代码内容进一步判断。
3.2有效语句数（Statements）：67 句，语句密度约为 63.8%（67÷105×100% ），代码紧凑程度尚可，但仍需留意逻辑分隔和可读性。
3.3分支语句占比（Percent Branch Statements）：22.4% ，处于相对合理范围，控制流逻辑复杂度处于可接受水平，利于代码理解与调试。
3.4方法调用语句（Method Call Statements）：40 次 ，方法间存在一定交互，但仅从此数据难以精准判断耦合度高低，需结合代码结构综合评估。
3.5注释率（Percent Lines with Comments）：0.0% ，严重低于理想状态，注释全无会给后续代码维护和理解带来极大困难，需尽快补充。
3.6类 / 接口数（Classes and Interfaces）：3 个 ，符合面向对象设计理念，功能拆分相对合理，有助于提升代码可维护性与可测试性。
3.7方法数 / 类（Methods per Class）：2.00 个 ，在小型类方法数量参考范围（3 - 5 个）下限附近，或许可进一步优化方法拆分，增强类的内聚性。
3.8方法平均语句数（Average Statements per Method）：8.50 句 ，小于推荐值（≤15 句） ，方法较为简洁，符合代码编写的良好规范，可读性和可维护性有保障。
3.9最复杂方法行数（Line Number of Most Complex Method ）：37 行 ，对应方法为 Elevator.run () ，虽然未远超常规，但仍可考虑是否能进一步拆分简化，降低方法复杂度。

其实我的实际功能比起前两次作业其实没有本质上的区别，只是把类更好的优化合理了，增加了类的内聚性。电梯内的题目对于我来说难度实在还是太大了，我需要更加的努力学习，然后把老师讲的东西内容搞懂，来继续完善这个程序。

三、反思与总结

1. 学到的东西

首先最重要的是感觉自己算的上小白了，从什么都不会，经过这几次jian到能写一些简单的逻辑算法程序和一些简单的数组以及外部引入包的函数使用，搞清楚了public和private类名下的不同了。 终于从c语言里爬出来摸到了Java的边。然后以下是从电梯里错误学到的东西：

1.1输入处理问题：最初没有正确处理输入的格式，特别是忽略了"end"的大小写问题，导致程序无法正常结束。后来添加了equalsIgnoreCase来解决。

1.2方向判断错误：在第一版实现中，电梯方向切换逻辑不够严谨，有时会在处理完同方向请求后错误地继续移动。通过添加更严格的方向检查逻辑解决了这个问题。

1.3重复请求处理：在第二题中，忽略了题目要求过滤重复请求的要求，导致测试用例失败。后来通过使用Set来存储请求自动过滤了重复项。

1.4楼层有效性检查：最初没有对输入的楼层进行有效性检查，导致电梯可能尝试前往不存在的楼层。添加了minFloor和maxFloor的检查后解决了这个问题。

1.5外部请求转为内部请求：在第三题中，最初没有正确处理外部请求到达后将其目的地加入内部队列的要求，导致测试用例失败。修改后在处理外部请求时自动添加了内部请求。

2. 还需要学习的内容

2.1 学习更多的算法比如LOOK算法，根据同学的帮助和提醒，LOOK算法更适合解决这道题，这道题本质上也是考虑LOOK算法

2.2 学会现在IDE这种集成环境上测试运行，能帮助自己更快的找出错误，确保代码质量，并进行进行自我审查，检查是否有改进空间。

2.3学会考虑多个类请求之间的调动，比如第三题核心Controller中的调度算法实现（如同方向优先、请求合并等）。

2.4低于小型类可能存在类职责划分过细或方法拆分不充分的情况，需要进一步优化以提高内聚性.

3. 对课程的建议

3.1增加实际项目的例子，对当前讲的课题能够精准配套题目

3.2让同学互相检查代码

3.3多教一点编程实际技巧