java程序设计-01

**前言** -- 先简单总结一下这三周的作业题目吧

简单来说，这三周的题目大部分都挺简单的，只有一个关于电梯的题目有点难度，但是只要花时间认真思考也是可以完成的，之后我会对其进行重点介绍。那些简单题目之后我就不做过多的介绍了，而有些简单题目也让我遇到了一些问题，我之后同样会介绍到。
我们以周为板块来讲讲吧
-- week1
题目一 // 求身份证号校验位

简单题目，就不多介绍

题目二 // 求解一元二次方程

简单题目，但是我却遇到一点小插曲，我先写了QuadraticEquation类，然后写Main类，提交代码时却一直有一个测试点通过不了，
找了很久原因都没有通过，然后我就重新看题目（题目中有部分源码，有类的外框，里面内容省略），我发现题目中源码是先写了Main
类然后再写QuadraticEquation类，我仅仅只是调换了它们的顺序，结果测试点都通过了。--具体是什么原因（为什么交换一下顺序就会测试点全通过）我还是不太明白，但是我也吸取了教训，做题前一定要仔细认真看题目。

题目三 // 正则表达式训练-验证码校验
题目四 // 正则表达式训练-QQ号校验
简单题目，也不多做介绍

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

刚开始有一点点难度，但是只要多花点时间就能解决，这次只是在Main中完成，没有细分设计多个类（相对降低了难度），只设计了一个电梯Light类。我先来简单分析一下这个程序的基本逻辑吧。

首先，刚开始根据初始数据（电梯内外队列的头元素的楼层）判断电梯的运动方向，电梯运动超距离最近的楼层；
其次，每运动一层都要按一定的格式打印当前楼层和电梯运动方向；
然后，判断电梯当前楼层是否需要开门（根据当前楼层是否和电梯内外队列的头元素的楼层相等），开门则删除相关元素并根据电梯内外队列的头元素的楼层及外队列的运动方向来判断是否需要改变电梯的运动方向（根据电梯内外队列的头元素的楼层以及电梯的运动方向和当前楼层），不开门则电梯按原运动方向运动；
最后，如果两个队列都为空，则电梯停止。

代码提交过程中出现了各种问题，以及后来我的解决办法。

（1）非零返回

因为之前没有出现过这个问题，我就很困惑非零返回是什么错误，我上网查找什么原因会导致非零返回，经过分析，初步判断是因为数组越界造成的，然后修改light中相关的代码，然后再提交时就发现没有非零返回了，可是又出现了答案错误。
（2）答案错误

那这肯定是逻辑思路出现了问题，尽管题目中的样例能通过，但是不代表思路没有问题。然后开始痛苦的修正思路环节，或者是说有些特殊情况没有考虑到，
例如当有<3,DOWN>,3,UP>在队列中挨着时，应该开两次门，当时就没有考虑到，等等情况。改到觉得逻辑没有问题时提交代码，没有答案错误了，可是又出现了运行超时。
（3）运行超时

第一想法是，代码冗长导致的，然后开始修改优化代码，最后提交时还是运行超时，然后我就觉得是不是陷入死循环了，然后在IDEA中调试，用题目中的样例测试没有出现问题，觉得会是边界值那出现问题，测试发现当有超过最小楼层时出现了死循环，最后修改成功了。


-- week2
题目一 // 点与线（类设计）

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

分成几个类（Controller,Elevator,RequestQueue,ExternalReques）
控制类：Controller
实体类：Elevator,RequestQueue,ExternalRequest
RequestQueue,ExternalRequest组合关系
Controller,Elevator依赖关系
Controller,RequestQueue依赖关系
这一次的电梯题目其实和上一次的差不多，只是这次的需要通过设计各种类来解决问题，然后相比于上次这次的数据输入的处理上也有区别，Controller类里面设计了去重的方法，用来删去输入数据中的连续出现的相同请求，达到提高程序设计思维的目的。

题目二 // 蒙特卡罗方法求圆周率

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

前两次电梯的再一次迭代升级，相较于前一次，初始条件（队列中的各元素）的给出方式有所改变，思路逻辑也发生了一点变化。然后基于上一次代码进行了迭代优化，将之前主方法的复杂过程分解成多步更小的过程然后放入到Controller类中，同时增加了注释，提高了代码的可读性。
我还是讲解一下这道题目的思路逻辑。
首先，用正则表达式来获得初始条件信息，和前几次不同的是，这次电梯外的请求的信息被分为了Source和Destination两个参数。而电梯内的也还是只有一个Destination，然后基本思路同前两次的电梯题目如出一辙，这里我就不做过多的解释，需要注意的是，当有电梯外的元素出队时，就需要将电梯外的元素中的Destination加入到电梯内的队列的队尾。
最后再总结这三周的小小的经验和心得体会吧。
小小的经验：
（1）之后做题一定要先认真看题目，不能遗漏了题目中的需求。
（2）之后遇到非零返回问题，先检查是否有越界的情况出现。
（3）之后遇到运行超时问题，优先检查是不是出现死循环问题，其次是优化时间问题。
心得体会：
（1）对于java中关于类的设计与应用有了更深的领悟，但是还有很多不足之处，之后还是要多花时间取揣摩。
（2）对于正则表达式的运用更加熟练，不过后续还是要多加训练。
（3）初次用java编写解决相对更加综合型的问题（这次的电梯问题），很好的锻炼到了自己的思维逻辑问题。