关于面向对象程序设计的第一阶段大作业总结

一、前言
本次三次题目集聚焦 “单部电梯调度系统”，是面向对象编程的迭代式实践。涉及的知识点包括 Java 类与对象、枚举封装、集合框架（LinkedList）、单一职责原则（SRP）、电梯调度算法及输入校验。但对我而言，这些知识点的综合应用难度远超预期 —— 三次大作业中，我仅完成了基础输入解析和部分简单功能，核心的调度算法、类职责拆分等关键需求均未完全实现，大部分测试点处于未通过状态。
题量上，每轮仅 1 道核心题，但复杂度的阶梯式递增让我难以跟上：
题目集 1（大作业 1）：仅实现了 “接收请求、简单移动”，未处理同方向优先调度；
题目集 2（大作业 2）：尝试拆分类，但类间耦合更严重，功能反而倒退；
题目集 3（大作业 3）：按要求搭建了类结构，但类间协作、外部请求转内部队列等逻辑完全卡壳。
难度层面，我最大的障碍是 “从功能逻辑到面向对象设计的思维转变”：题目集 1 还能勉强用单类写点代码，题目集 2 开始的类拆分、题目集 3 的单一职责原则，让我陷入 “不知道该把哪个逻辑放哪个类” 的迷茫，最终大部分代码停留在 “能运行但不符合需求” 的状态。
二、设计与分析：三次尝试的真实困境
（一）题目集 1：单类勉强跑通基础功能
题目集 1 的核心需求是实现电梯基础运行逻辑，但我仅完成了 “接收请求、逐层移动、开关门” 的表面功能，核心的 “同方向优先” 调度完全未实现。

1. 类结构设计
   仅写了 1 个Elevator类和 2 个枚举类（Direction、State），所有逻辑全部堆在Elevator中：
   属性：currentFloor（当前楼层）、minFloor/maxFloor（楼层范围）、direction（方向）、internalRequests（内部队列）、externalUp/externalDown（外部队列）；
   方法：仅实现了addRequest（接收请求）、move（逐层移动）、openDoor/closeDoor（开关门），调度逻辑processRequests完全未写。
2. 代码实际情况
   通过 SourceMonitor 分析，我的代码存在严重问题：
   
   圈复杂度高达 15，原因是move方法里混杂了 “移动、判断是否开门、队列遍历” 等所有逻辑，且没有拆分分支。例如，我没有判断 “同方向请求”，而是不管方向，直接按请求添加顺序处理 —— 输入<3,UP>和<6,DOWN>时，电梯先到 3 楼，再到 6 楼（而非处理完同方向后转反向），完全不符合调度规则。
3. 类图
   
   ** （注：实际类图中，Elevator类直接持有 3 个队列，无任何逻辑拆分，枚举类仅作为常量使用，未参与复杂判断）
   （二）题目集 2：类拆分失败的耦合灾难
   题目集 2 要求 “强化类的概念”，但我对 “类职责” 毫无概念，拆分后的代码反而更混乱，功能比题目集 1 还弱。
4. 类结构设计
   勉强新增了Request类和RequestQueue类，但完全没理清职责：
   Request 类：仅定义了floor（楼层）和direction（方向）属性，无任何方法；
   RequestQueue 类：仅用LinkedList存储Request对象，无增删查的封装方法；
   Elevator 类：仍持有所有逻辑，且需要直接操作RequestQueue的LinkedList，耦合度比题目集 1 还高。
5. 代码实际情况
   类数量增加了，但复杂度未降反升：
   
   例如，Elevator类中直接写requestQueue.getRequests().remove(request)，完全违背封装原则。且因RequestQueue无判断请求方向的方法，Elevator类不得不重复写 “遍历队列判断方向” 的代码，导致代码冗余且易出错 —— 处理外部下行请求时，多次出现 “漏判方向”，电梯反向移动的情况。
6. 类图
   

** （注：类间是 “强依赖” 而非 “协作”，Elevator直接操作RequestQueue的私有属性，Request类无任何行为，仅作为数据传输的 “傀儡”）
（三）题目集 3：类结构搭好了，逻辑完全卡壳
题目集 3 要求遵循单一职责原则，拆分电梯、乘客、队列、控制类。我按题目给的类图搭好了类结构，但类间协作、调度逻辑完全无法实现，最终代码仅能接收输入，无法触发电梯移动。

1. 类结构设计（仅搭框架，无核心逻辑）
   枚举类：Direction、State（仅定义常量，未使用）；
   Elevator 类：仅实现了 get/set 方法和isValidFloor，无任何状态管理逻辑；
   Passenger 类：定义了sourceFloor和destinationFloor，无构造方法之外的其他方法；
   RequestQueue 类：定义了内部 / 外部请求队列，仅实现了add方法，无remove和check方法；
   Controller 类：持有Elevator和RequestQueue实例，但processRequests、determineDirection等核心方法完全空白。
2. 代码实际情况
   
   调度算法、方向判断、外部请求转内部队列

例如，Controller的processRequests方法仅写了 “判断队列是否为空”，后续的 “确定方向、触发移动、处理请求” 均未实现；RequestQueue没有 “检查当前楼层是否有请求” 的方法，导致电梯无法判断是否需要开门。
3. 类图（框架版）
**

（注：类结构与题目要求一致，但类间无有效协作 ——Controller无法调用RequestQueue的查询方法，Elevator无法接收Controller的移动指令）
三、实验总结：从 “完全不会” 到 “勉强入门”
（一）题目集 1：连 “队列排序” 都搞不懂的基础困境
外部请求队列的排序逻辑完全空白
问题：我不知道 “同方向优先” 需要先对队列排序 ——externalDownRequests应该按楼层降序排列，但我直接用LinkedList无序存储。输入<3,UP>和<6,DOWN>时，电梯先到 3 楼，再到 6 楼（同方向优先规则未生效），导致该测试点 0 分。
尝试解决：查资料知道需要排序，但不知道怎么写 —— 尝试用Collections.sort，但不会写自定义比较器，最后放弃，队列始终无序。
耗时：3 天（从知道要排序到放弃，全程卡壳）。
无效楼层校验写了但没用
问题：虽然写了isValidFloor方法，但在addRequest中忘记调用，导致输入<21>（maxFloor=20）时，程序直接崩溃（ArrayIndexOutOfBoundsException）。
修复过程：调试时看到错误信息，才发现忘记调用校验方法，加上后无效请求被过滤，但花了 2 小时才定位到问题（因为不知道怎么看异常堆栈）。
测试结果：该测试点从 0 分提升至 10 分，但其他调度相关测试点仍为 0 分。
移动逻辑写死，无法适配多请求
问题：最初的move方法是 “针对单个请求移动”，处理完一个请求后，不会自动处理下一个。例如输入<3,UP>和<5>，电梯到 3 楼后停止，不会继续处理 5 的请求。
尝试解决：想写一个循环遍历队列，但不知道怎么 “处理完一个请求后，重新判断下一个目标”，最后只能手动调用move方法，无法实现自动连续处理。
结果：多请求场景完全无法处理，该测试点得 0 分。
（二）题目集 2：类拆分越拆越乱的耦合陷阱
不知道 “类职责” 是什么，盲目拆分
问题：看到题目要求 “强化类的概念”，就随便拆了Request和RequestQueue类，但不知道Request该有什么方法、RequestQueue该管理什么。例如，RequestQueue没有getDownRequests方法，Elevator类不得不重复遍历队列判断方向，代码比题目集 1 还冗余。
求助过程：问了同学，才知道 “RequestQueue应该封装队列的增删查逻辑”，但自己还是不会写 —— 尝试写getDownRequests方法，却不知道怎么返回当前楼层的下行请求，最后不了了之。
结果：类拆分后，代码量增加了 30%，但功能更弱，调度逻辑完全失效。
类间调用报错，不知道怎么调试
问题：Elevator类调用RequestQueue的addRequest方法时，报NullPointerException，因为忘记初始化RequestQueue对象。
调试过程：花了 1 小时找错误，不知道怎么看 “空指针在哪一行”，最后在同学指导下，才发现是RequestQueue未实例化，加上requestQueue = new RequestQueue()后解决。
反思：基础的 “对象初始化” 知识点没掌握，导致低级错误，浪费大量时间。
枚举类用错，方向判断失效
问题：Request类的direction属性定义为String类型，而非Direction枚举，导致判断方向时出现字符串匹配错误（例如输入 “UP”，代码里写的是 “Up”，大小写不匹配）。
修复：把direction改为Direction枚举，但不知道怎么从输入字符串转换为枚举，最后硬编码if (input.equals("UP")) direction = Direction.UP，代码冗余且易出错。
（三）题目集 3：类结构搭好了，逻辑完全不会写
外部请求转内部队列的时机完全搞反
问题：题目要求 “电梯到达源楼层后，将目的楼层加入内部队列”，但我在接收外部请求时就直接加入内部队列。例如输入<5,4>，电梯从 1 楼出发时，内部队列已有 4，导致电梯在 3 楼就尝试处理 4 的请求（开门），完全不符合逻辑。
尝试理解：反复看题目描述和样例，花了 2 小时才明白 “要等电梯到源楼层开门后再入队”，但不知道怎么在Controller中判断 “电梯是否到达源楼层”—— 因为Elevator类没有 “当前楼层变化时通知 Controller” 的逻辑。
结果：该核心需求未实现，测试点得 0 分。
Controller 类不知道该怎么 “控制” 电梯
问题：Controller类持有Elevator和RequestQueue实例，但不知道怎么写processRequests方法 —— 不知道如何 “从队列取请求→确定电梯方向→触发电梯移动→处理请求”。
尝试写代码：仅写了以下几行，就卡壳了：
public void processRequests() {
if (requestQueue.isEmpty()) {
elevator.setState(State.STOPPED);
return;
}
// 后面不知道怎么写：确定方向、移动电梯、处理请求
}

求助结果：同学给我讲了 “先判断当前方向，再找同方向的请求”，但我还是不会用代码实现，最后Controller类仅能判断队列是否为空，无其他功能。
类间协作完全缺失，代码就是 “孤立的类集合”
问题：Elevator类的currentFloor变化后，Controller类不知道；RequestQueue有新请求时，Controller类也不会自动触发处理。例如，添加新请求后，电梯仍保持静止，需要手动调用processRequests方法。
结果：整个系统完全无法自动运行，仅能接收输入，无法触发任何移动或开关门操作，测试点全 0 分。
四、改进建议：基于 “基础薄弱” 的真实可行优化
（一）个人层面：先补基础，再谈设计
分步实现功能，拒绝 “一口吃胖子”
针对电梯调度这类复杂问题，应按 “最小功能→逐步扩展” 的思路：
第一步：实现 “接收请求→验证合法性→加入队列”；
第二步：实现 “电梯逐层移动→输出当前楼层”；
第三步：实现 “判断当前楼层是否有请求→开关门”；
第四步：实现 “同方向优先调度”。
我之前直接尝试 “一步实现所有功能”，导致每个环节都卡壳，后续应按步骤拆解，每完成一步就测试，避免全盘崩溃。
强化 “类与对象” 的基础认知
目前我对 “类职责”“封装”“耦合” 的理解仅停留在理论层面，后续应：
先模仿简单类的设计（如RequestQueue类，先实现add/remove/check等基础方法）；
避免盲目拆分类，先明确 “这个类要解决什么问题”，再设计属性和方法；
多分析优秀代码的类结构，理解 “为什么这个逻辑要放在这个类里”。
掌握调试技巧，减少无效耗时
之前因不会调试，很多低级错误（如空指针、未初始化）浪费了大量时间，后续应：
学会看异常堆栈（知道错误在哪一行、是什么类型）；
学会用System.out.println打印关键变量（如currentFloor、队列状态），定位逻辑错误；
针对电梯调度，可打印 “当前楼层、当前方向、队列内容”，清晰看到每一步的状态变化。
（二）题目层面：增加 “基础引导”，降低入门门槛
提供 “功能分步指导”
对于基础薄弱的学生，可在题目中给出 “分步实现建议”，例如：
题目集 1：先实现输入解析和无效请求过滤，再实现移动和开关门，最后实现调度算法；
每一步给出对应的测试用例，让学生知道 “这一步要达到什么效果”，避免盲目编码。
提供 “类设计模板”
题目集 2 和 3 的类拆分对基础薄弱的学生难度过高，可提供简化的类设计模板（如给出类的属性和方法签名），让学生先理解 “类该有什么”，再尝试实现方法，而不是让学生从零设计类结构。
增加 “常见错误案例”
提供学生常犯的错误案例（如队列未排序、类未初始化、外部请求入队时机错误），并给出修复思路，帮助学生避开 “重复踩坑”，减少无效耗时。
五、总结：正视差距，明确后续学习方向
（一）本次迭代的真实收获
认清了自己的基础短板
之前以为 “类与对象” 的基础学会了，但实际应用时才发现，连 “封装”“耦合” 的基本逻辑都不会落地 ——RequestQueue类不会封装队列管理逻辑，Controller类不会协调其他类，暴露了 “理论与实践脱节” 的严重问题。
学会了 “拆解问题” 的初步思路
三次作业的失败让我明白，复杂问题不能直接上手写代码，必须先拆解成小功能，每完成一个小功能就测试，否则很容易全盘崩溃。例如，电梯调度的核心是 “调度算法”，但我之前跳过了 “队列管理”“移动逻辑” 等基础步骤，直接写调度算法，导致完全无法实现。
积累了 “踩坑” 的经验
虽然大部分功能未实现，但通过调试空指针、无效请求、队列排序等问题，学会了一些基础的错误处理技巧（如校验输入、初始化对象），后续遇到类似问题时能更快定位。
（二）后续必须补的知识点
Java 基础：类与对象的实战应用
重点学习 “封装”：如何设计类的属性和方法，避免外部直接操作私有属性；
学习 “类间协作”：如何通过方法调用实现类间通信（如Controller调用Elevator的move方法）；
掌握集合框架的基础用法：LinkedList的遍历、删除、排序，PriorityQueue的自定义比较器。
逻辑思维：复杂流程的代码实现
电梯调度的核心是 “多条件判断 + 循环”，后续应：
先画流程图（如 “调度算法的流程”“电梯移动的流程”），再根据流程图写代码；
多做逻辑题，锻炼 “条件判断” 和 “循环控制” 的能力（如判断同方向请求、找下一个目标楼层）。
调试能力：快速定位错误
学会看异常堆栈信息（错误行号、错误类型）；
学会用System.out.println打印关键变量，跟踪程序执行流程；
尝试使用 IDE 的调试工具（如断点、单步执行），提高调试效率。
（三）最后反思
三次电梯调度作业的失败，让我深刻认识到 “编程不是‘背代码’，而是‘解决问题的思维’”。之前学习 Java 基础时，仅满足于 “能看懂代码、能运行简单程序”，但缺乏 “主动设计、解决复杂问题” 的能力。后续我会放下 “怕做不出来” 的心理，从基础功能开始，一步步拆解问题，先补好类与对象、逻辑思维的基础，再尝试挑战复杂的设计需求。虽然目前差距很大，但我明白 “每一次踩坑都是进步”，只要正视不足、稳步积累，总能慢慢掌握面向对象编程的核心思想。
（Blog 链接：https://www.cnblogs.com/nchu-jcc）