在本学期我第一次接触到Java这门面向对象的编程语言此前我已经持续使用了两年多的面向过程的C语言编程并一直认为掌握好C语言这一门就能解决大部分的问题但随着这几次从用Java语言实现的电梯调度程序再到每一次的迭代我逐渐意识到Java这门编程语言确实有它的独到之处并且在一些复杂问题的实现上与C语言相比有更多的优势。就比如在第一次的题目集中从简单的算法实现如身份证校验和正则表达式匹配验证码、QQ号到面向对象的类设计一元二次方程最后是复杂的系统模拟电梯调度。涉及到字符串处理、数学计算、正则表达式、面向对象编程和状态机管理等各个方面的知识点题量也是从十几行代码的小任务逐步上升到上百行的大项目在难度上由浅入深前四题较为简单侧重基础技能而最后一题电梯调度是用Java语言解决实际问题的综合实践用到Java编程的很多知识对于第一次接触Java语言的我难度不小然后是第二次的题目集题目整体围绕面向对象设计展开逐步提升复杂度和实践要求7-1是基础类设计聚焦点和线的抽象帮助巩固封装和基本方法7-2引入设计原则SRP通过雨刷系统模拟训练多类协作和状态管理7-3则是综合性应用将前期电梯问题迭代为多类设计强调职责分离和调度逻辑。知识点覆盖从类定义、属性方法到设计原则和算法实现题量逐题递增这时候我才真真切切的感受到Java编程的真正面目最后是第三次的题目集题目体现了从基础业务逻辑到算法仿真再到系统设计迭代的过程7-1通过销售佣金计算训练面向对象设计和SRP原则应用7-2引入蒙特卡罗方法将数学理论与编程实践结合7-3作为电梯系统的第三次迭代加入乘客类并改变请求格式考验系统架构的适应性和扩展性。知识点覆盖商业逻辑、概率算法和复杂系统设计题量逐题增加7-3尤为庞大难度也相比前2次题集增大了不少。接下来我将从代码设计分析踩坑心得改进建议和总结四个方面重点对三次的电梯调度的迭代开发进行详细讲述。设计与分析第一次大作业类图设计如下代码参数分析如下思路分析整体设计思路我首先思考的是如何用面向对象的方式来模拟电梯系统。电梯是一个很常见的现实物体我觉得把它抽象成Java类应该挺合适的。电梯有状态当前楼层、运行方向有行为开门、关门、移动还有要处理的各种请求。所以我就决定创建一个Lift类来封装所有这些特性。枚举类型的选择我选择用枚举来表示方向因为电梯的方向只有两种固定的状态向上和向下。用枚举比用字符串或者整数更安全不容易出错。比如如果我用字符串UP和DOWN万一拼写错了编译器也发现不了但用枚举的话如果写错了Java会直接报错更便于我去定位代码错误。请求处理的思考电梯要处理两种请求内部请求电梯里面的按钮和外部请求楼层上的按钮。我觉得这两种请求不太一样所以分别用不同的类来表示。内部请求只需要知道要去几楼外部请求还需要知道方向。我用了队列Queue来存储这些请求因为请求是按照时间顺序来的先来的请求应该先被处理这正好符合队列先进先出的特性。电梯运行逻辑的设计这部分是最难的我花了很多时间思考电梯应该怎么运行。我的想法是电梯应该先处理当前楼层的请求然后再决定下一步怎么走。如果当前楼层有请求不管是内部还是外部的都应该停下来处理。关于方向的调整我想到了现实中的电梯当电梯向上运行时如果上面没有请求了就会改变方向向下反之亦然。所以我写了一个方法来检查当前方向是否还有未处理的请求。去重逻辑的考虑在实际使用电梯时如果连续按同一个楼层的按钮电梯只会停一次。所以我在添加请求时加了去重判断避免同一个请求被多次加入队列同时当电梯运行到这一楼层时应该将这一楼层对应的同方向外部请求及时的从外部请求队列中移除。输入处理的思路用户输入可能有很多种情况我需要考虑各种错误处理楼层范围是否合法最低层不能大于最高层只有按规定的输入格式,或*才能将对应的外/内请求加入到对应的队列中。楼层数字是否在有效范围内方向是否合法不能在一楼按下行顶楼按上行第二次大作业类图设计如下代码参数分析如下思路分析与改进这次我对电梯程序进行了彻底的重构之前的版本把所有功能都塞在一个大类里感觉代码有点乱就像把所有的衣服都扔进一个柜子找起来特别麻烦完全不符合Java“类”的有效使用在经过了一周对Java的加深学习后现在我学会了单一职责原则就是把不同的功能拆分到不同的类中每个类只负责一件事情这样不仅可以使代码的结构更清晰也更方便后续的代码复用和其他功能的添加和改进。我设计了四个主要类Lift负责电梯状态ReqList管理请求列表ControlUnit控制电梯运行Main处理程序入口。这样分工明确就像组建了一个小团队每个人各司其职。枚举类型的完善我发现之前的方向枚举只有UP和DOWN但现实中电梯有时候会停在某层不动所以我新增了IDLE状态。还增加了Status枚举来表示电梯是移动还是停止。这样电梯的状态描述更加精确了就像给电梯装上了更详细的状态指示灯。请求管理的优化这次的ReqList类让我很有成就感之前用队列虽然简单但功能有限。现在我用了ArrayList可以更灵活地管理请求。我还专门为外部请求创建了OutsideReq类重写了equals和hashCode方法这样在比较请求时更加准确。去重逻辑也改进了现在不是简单比较最后一个请求而是用equals方法全面比较避免了重复请求的问题。大大的扩展了代码的使用场景可以更贴合现实中的电梯调度情况。单例模式的应用Lift类我用到了单例模式因为整个系统只需要一个电梯实例单例模式确保不会意外创建多个电梯大大的贴合了题目的要求同时避免了意外创建多个电梯时产生的其他错误。控制单元的智能化ControlUnit是这个系统的大脑我花了很多心思来完善它。最大的改进是增加了循环次数限制避免程序陷入死循环。之前有用题目样例测试时输出结果出现了死循环的情况所以这次我加了安全阀更有效的避免了测试过程中带来的死循环的情况为后续为适应更多情况的程序迭代打下了基础。方向判断逻辑也更加智能了。现在电梯会考虑两种情况改变方向到达边界或者当前方向没有请求。我还分别写了检查上方请求和下方请求的方法逻辑更加清晰代码的复用性也大大的增强了。状态管理的精细化我注意到之前电梯状态输出有点混乱有时候会重复输出相同状态。现在我用lastPrintedLevel和lastPrintedDir记录上次输出的状态只有状态变化时才输出这样运行日志更加清晰易懂同时也更贴切了题目的具体要求。电梯的移动逻辑也改进了通过dirFlag参数控制移动行为这样可以在改变方向时进行特殊处理这是针对输入只有单个外部请求或内部请求的情况具体是在探测具体的测试点要求中发现的。请求处理的协同机制当一个内部请求被处理时我让电梯自动清除同楼层同方向的外部请求。这个设计模拟了现实情况如果有人从电梯内按了5楼而5楼正好有人按了上行键那么电梯到达5楼时这两个请求应该同时被满足进而从对应的请求队列中移除。错误处理的加强