面向对象程序设计题目集5~7总结

面向对象程序设计题目集5~7总结

1. 前言（总结三次题目集的知识点、题量、难度等情况）

题目集5

一共有五道题。前四题为基础的Java程序设计题目，难度较低，可以帮助Java初学者在实践中理解基础知识的运用，比如循环、字符串操作、异常处理以及布尔方法的使用，还有方法的调用与定义，初步学习类与主方法的定义与使用、正则表达式的训练等等。

题目集6

一共有三道题。前两题主要考察类的设计。同时也考察了私有属性、属性的getter和setter方法使用，难度较题目集5来说要难一点点，因为涉及到了多个类的设计。

题目集7

一共有三道题。前两题与上一个题目集一样，考察多个类的设计以及函数方法的设计使用，同时也考察了对题目的理解能力。

[电梯类迭代设计]

这三次的迭代题目难度很高，最大的难点是算法设计这些逻辑方面的问题。题目集5的单部电梯调度程序为初次题目，但是由于初次接触这种类型的题目和初学Java，所以无从下手。题目集6的单部电梯调度程序增加了类设计的要求，并且增加了一些新的情况要求对其进行处理。题目集7的单部电梯调度程序要求取消上次题目集中的一个类，加入一个新的Passenger类，并且对输入输出的部分内容要求进行了改变。这三次题目都是在前一次基础上进行迭代，难度也逐渐增加。

1. 设计与分析

由于前几道题目难度还好，除了语法与C语言不同外没有什么太大的区别，所以这里重点分析三次电梯类程序。

1. 题目集5

题目描述

设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。
电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
使用键盘模拟输入乘客的请求，此时要注意处理无效请求情况，例如无效楼层请求，比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态，当没有请求时，电梯停留在当前楼层。
请编写一个Java程序，设计一个电梯类，包含状态管理、请求队列管理以及调度算法，并使用一些测试用例，模拟不同的请求顺序，观察电梯的行为是否符合预期，比如是否优先处理同方向的请求，是否在移动过程中处理顺路的请求等。为了降低编程难度，不考虑同时有多个乘客请求同时发生的情况，即采用串行处理乘客的请求方式（电梯只按照规则响应请求队列中当前的乘客请求，响应结束后再响应下一个请求），具体运行规则详见输入输出样例。

这是第一次的代码SourceMontor分析：

• 分支语句占比总语句数的百分比为25.8%，此比例较高，说明此代码中分支逻辑较多，可能增加代码复杂度，相对来说不易于理解与维护。
• 在雷达图中注释语句占总语句数的百分比最低，为0.0%，说明我的代码可读性较差，难以理解和维护，因此要增加代码的注释比例。
• 每个类中的方法数量平均为6个，每个方法中的平均语句数量为8.5条，这表明代码的方法复杂度中等。可能是因为这段代码包含了一些逻辑较为复杂的操作，导致方法中的语句数量相对较多。
• 最复杂方法的行号为50，提示我们代码中存在较为复杂的部分，可能需要进一步优化以降低复杂度。

结合实际代码来看，if else分支语句较多，这使得代码更复杂了，也更容易出错，应该要简化条件判断逻辑；然后部分方法写的太长了，应该拆分成多个小方法，这样才能便于维护，出错时也方便调试。还有就是运行结果不对，应该是出现了逻辑方面的错误。

1. 题目集6

题目有所变化：对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，具体设计如下类图。

电梯运行规则与前阶段单类设计相同，但要处理如下情况：

• 乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
• 乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>

第二次的代码SourceMontor分析：

• 分支语句占比总语句数的百分比为23.5%，此比例较低，说明此代码中分支逻辑较少，更易于理解与维护。
• 在雷达图中注释语句占总语句数的百分比最低，为0.0%，说明我的代码可读性较差，可能也难以理解和维护，因此要增加代码的注释比例。
• 每个类中的方法数量平均为3.57个，每个方法中的平均语句数量为4.68条，这表明代码的方法复杂度较低。可能是因为这段代码包含较多的简单方法，使得方法的平均语句数量较低，这可能是代码复杂度较低的一个表现。
• 最复杂方法的行号为171，提示我们代码中存在较为复杂的部分，可能需要进一步优化以降低复杂度。

结合实际代码，我的代码缺少注释，可读性不够。运行结果来看也是不对的，应该是逻辑上还有问题，电梯逻辑在处理完同方向上的请求后没有正确切换方向来处理反方向的请求。

1. 题目集7

题目有所变化：

对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，具体设计如下类图。

电梯运行规则与前阶段相同，但有如下变动情况：

• 乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
• 对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）

第三次的代码SourceMontor分析：

• 分支语句占比总语句数的百分比为13.9%，此比例较低，说明此代码中分支逻辑较少，更易于理解与维护。
• 在雷达图中注释语句占总语句数的百分比最低，为0.0%，说明我的代码可读性较差，可能也难以理解和维护，因此要增加代码的注释比例。
• 每个类中的方法数量平均为3.86个，每个方法中的平均语句数量为3.33条，这表明代码的方法复杂度较低。可能是因为这段代码包含较多的简单方法，使得方法的平均语句数量较低，这可能是代码复杂度较低的一个表现。
• 最复杂方法的行号为135，提示我们代码中存在较为复杂的部分，可能需要进一步优化以降低复杂度。

结合实际代码，这是我运行结果与正确答案最接近的一次，但还是差了一点，就是在处理当前楼层与开门关门逻辑的时候有点问题，一直修改但是也没改对。然后依旧是我没有写代码注释的问题。

1. 踩坑心得（失败原因）

这三次的电梯迭代题目我都没有做出来。第一次的题目虽然没有要求多个类设计和单一职责原则，但是由于没有遇见过这样的题，同时也是初学Java，许多语法都不熟悉，同时对电梯运行的流程也就是逻辑方面不清楚，导致设计的时候思路很混乱，所以没有做出来。

第二次题目加入了分类设计的要求，这让我的思路清晰了一点，这次的代码最开始运行超时，是因为循环嵌套有点多，后面改进了一下，但是运行结果不对，分析后发现是因为我的请求调度没有顺序性，也是设计逻辑上有些问题。

第三次题目改变了乘客请求输入要求，也改掉了一个类。在上一次的基础上修改代码，但是还是没有成功，我的代码比正确答案少了两行，应该是在电梯接受内部和外部请求的逻辑上出了问题。

1. 改进建议

1. 我们应该先构建清晰的对象模型，再开展编码工作。在实际开发中，程序的复杂性往往来自对象之间的交互。因此在开始编码前，应通过类图或流程图将系统中涉及的对象（例如电梯、乘客、请求等）以及它们的职责明确建模。这有助于理清系统结构，减少后期逻辑混乱和代码重构的风险。

2. 要严格遵循单一职责原则，避免类功能过载。一个类只应负责一件事情。例如，电梯类应只处理电梯本身的状态与移动，不应承担调度逻辑；调度器负责控制流程；请求类负责表达乘客的请求意图。职责划分明确，有利于代码维护和测试，也便于逐步调试问题。

3. 不要将请求与执行混为一谈。程序应该以输入为驱动，根据输入生成请求队列，再统一调度执行。内部请求与外部请求应在数据层明确区分，在逻辑层统一处理，不应该在执行过程中调整优先级或插入新任务。

4. 调试过程重在“流程思维”，而不是逐句排查。当程序结果不符合预期时，从整体流程入手，逐步模拟每一步的状态变化，找出逻辑错误的原因。通过纸面推演或打印状态信息，可以更快定位错误源头。不要依赖零散的 if 判断修补逻辑漏洞，而是应该从流程设计本身重新审视是否合理。

1. 总结

通过三次关于电梯调度系统的题目练习，我对 Java 编程语言的理解有了更深入的提升

1. 在电梯题目的不断迭代中，我学会了如何从现实场景中提取对象（如电梯、乘客、请求、控制器等），并利用类与方法合理分工，建立较为清晰的数据模型和调度结构。
2. 单一职责原则（SRP）与模块化思维得到了训练。我更为深刻地理解了 “让一个类只负责一件事”这一原则。通过把请求解析、电梯状态管理、任务调度等功能进行解析，我的程序结构越来越清晰，调试与拓展难度也随之下降了。
3. 我在类与类的协作设计方面、算法设计方面等也欠缺许多，尤其是数据结构与算法的结合能力，代码的运行效率也还需要优化，代码的可维护性与可读性还需要增加。
4. Java课程方面，线下课程比较好，老师会以实例讲解并加以练习，但是线上课程学习效果不太理想；目前的作业难度（完成时间期限、题目本身）大部分没什么问题，但是感觉大部分人的普遍水平有时候和题目难度不太匹配，很多东西要靠自己了解，需要额外花时间，所以会显得时间很紧，学习起来和上学期C语言相比压力很大，有时候会很焦虑；目前做了两次实验，难度在循序渐进，这样就很适合初学者。总之没什么大问题吧。我会加油学习的，希望以后可以慢慢进步。