Blog1：5-7题目集总结

前言：

从开始学习java到现在已经过去了一个半月了，由于在上个学期有学习c语言的基础，对Java的入门学习中还是有一定的接受能力的。在初期的java学习中，基本是通过在csdn或通过ai来学习语法知识，然后再做老师发的题目集来学习的。最初的几个题目集，大多是以前c语言的基础题改成java语言的形式，只要掌握了基础的Java语法，难度并不高。
但到了题目集5之后，难度陡然上升，题目集5一共五题，前四题是在c学习阶段对我来说比较困难的包含字符的题的java变种，同时也对正则表达式进行了一定的训练，第五题则是第一次大作业——单部电梯调度程序，在这一块我遇到了不小的困难，同时对其他同学们来说也是一样，到了快截止时都没几个人完成，但通过老师的指导与对问题的解析，我们的问题被慢慢化解。
题目集6一共三题，前两题难度不大，只要根据给好的主类代码，理解好类之间的关系，进行缺少的功能类代码的补写就行，而第三题就是对题集5中的电梯问题进行迭代升级，目的是为了解决电梯类职责过多的问题，类设计要求遵循单一职责原则，这次代码的迭代能够使类之间的关系更加明确，职责更专注，减少类之间的混乱度。
题目集7也是三题，前两题难度也不高，同题集6，第三题则是对电梯程序再次迭代，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则，这次迭代对电梯程序进行了完善，进一步接近实际情况中的电梯运行。

设计与分析：

第一次作业：

设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。
电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
使用键盘模拟输入乘客的请求，此时要注意处理无效请求情况，例如无效楼层请求，比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态，当没有请求时，电梯停留在当前楼层。
输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door

类图：

源码分析报表：

1.代码规模: 代码文件 Main.java 包含 150 行，语句数为 90，语句密度约为 0.60（90:150），代码的规模较为适中。
2.类分析: 总共有 3 个类，每个类平均有 3 个方法，方法数量适中，符合良好的设计原则。
3.代码注释: 注释行占比为 12.0%，注释比例相对较低，说明代码的可读性和理解性可能不高，写代码已经拼尽全力了O.o!。
4.代码结构: 最大块深度为 4 层，说明代码的结构较为复杂，可能影响代码的可读性。深度较大的嵌套结构可能导致理解困难。
5.复杂性分析: 方法 Elevator.move() 的复杂度达到 10，说明该方法的逻辑较为复杂，可能导致理解和维护上的困难。其他方法的复杂度相对较低，建议对复杂度较高的方法进行重构，这也许是因为java学习时间不长，对类方法的复杂程度无法较好的掌握。
6.方法调用: 方法调用的分布较为均匀，平均每个方法调用约 7.56 次，表明代码实用性较高，但过于复杂的方法可能影响调用效率和可测试性。

第二次作业：

对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类。
电梯运行规则与前阶段单类设计相同，但要处理如下情况：
乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>。

类图：

源码分析报表：

1.代码规模：代码文件 Main.java 包含 199 行，语句数为 127，语句密度约为 0.64（127:199），代码规模较为适中。
2.类分析：总共有 7 个类和接口，每个类平均约有 2.71 个方法，方法数量总体分布尚可，但类数量相对较多，需关注职责划分是否合理。
3.代码注释：注释行占比为 0.0%，注释比例极低，代码的可读性和理解性较差，由于自律性问题，我并没有投入过多的时间到大作业的编写，注释就没赶得及添加。
4.代码结构：最大块深度为 5 层，代码结构复杂性较高，深度较大的嵌套结构可能导致理解困难，影响代码维护。
5.复杂性分析：方法 Controller.processRequests () 的复杂度达到 9，逻辑有一定复杂性，可能带来理解和维护困难。平均复杂度为 2.89，整体不算过高，但还有待完善。
6.方法调用：从列出的方法看，各方法复杂度与语句数有差异，如 Controller.processRequests() 语句数 15、复杂度 9，Main.main() 语句数 18、复杂度 5。

第三次作业：

对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类。
电梯运行规则与前阶段相同，但有如下变动情况：
乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）。

类图：

本次作业我并没有完成，在时间管理与自主学习方面我还是比较欠缺，同时在程序迭代编写时，由于第一代程序与第一代程序的类的编写没有将方法关系理清，导致在这次代码迭代时，将之前类中的方法弄乱，同时，没有将新加的乘客类与之前类的关系联系起来，后面编写就越来越乱了。最本质的原因应该还是我没有将时间投入进去，没有专注于作业的完成，导致最后两天过于仓促，草草收场。

踩坑心得：

在第一次作业中，我遇到了不少程序错误，导致没有正确输出运行结果，比如，在电梯到达一个楼层停下后，输出了语句楼层，但是当判断玩应当改变方向后，会再次输出语句，导致输出重复，此问题可以加入一个isPrint判断是否输出来解决。像这样的错误在我初次编译时大概出现了三到五个，大多因为在编写程序时有情况考虑不周全导致，也有一部分是因为我在java的学习中语法掌握不牢固，一些基本类方法的运用不了解，但这也进一步对我修改bug的能力进行了增强。
第二次作业与第三次作业的问题在于我对时间管理不当，第二次迭代时编写的仓促为后面第三次代码的混乱埋下了伏笔，在后面的学习中应当避免这种情况，给自己留下充足的时间完善代码

改进建议：

在以后的代码编写中，我应当适当的增添代码注释，增强代码的可读性与理解性
同时应该降低代码复杂性，将复杂度较高的方法拆分为多个简单的方法，以提高可读性和可维护性。
再之，应当将部分类的职责分化，使类职责更加单一，符合（SRP）原则，这样可以在后续代码的修改与完善中更加顺利，比如我代码中的control类，方法过多，复杂度较高，应当按上面几点进行改进。

总结：

通过从开学到现在的阶段性学习，我慢慢的完成了从c语言到java的思想转变，学习了Java编译方法，了解到java编译器idea的方便性，学会了jdk库中一些基本类方法的使用，如：Scanner、Arrays、ArrayList等，但是在学习中的问题也慢慢暴露，时间管理的不当，导致我作业完成效率的低下，这点应当在以后尽量改正，端正学习态度。