OO入门之旅

经过OO的前三周课程，对java程序设计语言有了基本的了解，可以算作是基本的入门吧。

第一次作业：多项式加法

目的：熟悉java编程语言，体会过程式编程与面向对象编程的区别，了解正则表的基本使用

第一次作业要求使用C语言跟java两种语言一起实现。对于C语言最主要的流程是字符串的处理，转换为桶存的多项式，进行加减运算最后进行结果的输出。

其中最麻烦的部分是C语言的字符串处理部分，我采用的是有限状态机的方式处理，过程及其复杂麻烦，很容易出错，就连OO作业也逃不过28定理。其余的部分实现较为容易。

在使用java编程的时候，整个任务由两个部分构成，一是多项式部分，主要负责多项式格式的检查，并进行系数的提取。另一个类主要负责多项式的计算。

多项式部分：

　　多项式格式检查部分采用的是正则表达式，比C语言简单很多，语法需要一定时间的学习，以及尝试。格式检查完之后就采用正则表达式的捕获组进行多项式系数的提取。加入待计算的多项式队列。

　　多项式还有一个计算的方法（由于多项式的构造方法不同，我只有加法），负责多项式之间的运算。　　

　　多项式还有一个展示的方法，负责多项式结果的展示。

多项式计算部分：

　　字符串的输入

　　字符串的分割（正则表达式爆栈）

　　计算的流程，遍历多项式的列表进行运算。

遇到的难点及问题：

　　1.正则表达式的使用，因为一开始不太会正则表达式，所以匹配格式的时候会出现很多的问题。

　　2.正则表达式的爆栈处理，当需要匹配的字符串过大，会导致爆栈。关于爆栈的原因，进行了简单的了解。正则表达式匹配的引擎分两种——DFA与NFA，其中一个区别是他们的可回溯性，NFA是可回溯的（java等多种语言默认），DFA是不回溯的，所以其匹配的速度很快，但其功能性不如NFA。关于其匹配的原理请移步至   https://sine-x.com/regexp-1/

我作业中出现的bug：

　　1.使用输出中间结果的匹配方法，在de完bug之后忘了删除。以后就更加细心一点（其实是不太会调试，只能System.out.println，但现在不一样了，翻身农奴做主人）。

　　2.由于正则表达式爆栈，导致的bug，将要匹配的字符串分为多个短的字符串放入匹配，放入的标志是检查是否有“}”，但是这种方式出现了很对问题，{（1,3）能正常判错，但{（1,3）}+@，对于这种就失效，因为找到{（1,3）}后放入，而+@不会检查，所以会出现问题，但这样的bug很难发现。应该在最后判断是否到了字符串的尾，这个bug是在我测试别人作业发现的，幸好测我那个人没有发现。

对方作业中的bug：

　　按照错误分支树进行测试，没出现什么bug，但是对于极端的情况，比如“{}”作为输入，就会判错，对于这一类极端的情况很难考虑到，需要有扣分的决心才能找到。

类的分析：

　　这次实验较为简单，类的构成也比较标准，故不在此赘述，类图如下：

 

 

　　

　　这也算是对面向对象编程的基本入门。

第二次作业：实现傻瓜电梯（stupid elevater）。

　　遇到这个作业的时候，构思大概就是跟第一次作业差不多，第一部分是电梯的处理，过程跟第一次作业类似。这个请求的处理包括三个部分，一是电梯类，二是楼层类，三是请求类。电梯类主要处理电梯的请求，楼层类处理楼层的请求，处理完请求之后统一作为请求类存在于请求队列之中。然后由调度器类实现电梯的运行并将结果进行输出。

　　请求处理过程在此不再赘述（读者自己脑补），主要讲电梯的运行过程，由调度器负责实行。

　　调度器类：

　　每一次将请求队列中的一个请求进行答复。当电梯运行完一条指令之后。会根据电梯目前的运行状态跟后续的指令进行处理，判断同质请求等，并进行同质请求的输出。

　　此次作业比较简单，所以其实很多类都会显得十分的冗余。自己在写的过程中都觉得很多类都可以省去，没按照教学的方法写，以至于后来的ALS的电梯实现会比较困难与累赘。此次作业的类图如下。

　　从类图可以看出，结构还是比较清晰的，但是显得过程比较冗余，对于请求处理的部分完全可以用一个请求类代替，这样再需要一个调度器类进行结果运行就好了（仅仅是个人看法，其他类完全是尸位素餐）。

难点分析：

　　最主要的问题是同质的判断，我的方法是完成一个请求之后，遍历后面请求（请求发出时间小于等于该请求结束）。

bug：

　　此次作业出错的地方不多，但是在查bug的时候发现，有一个人因为没加#，错了一半多，功能完全正确，看着特别心疼，算是杀鸡儆猴吧。

第三次作业：ALS电梯

　　这次的电梯的调度策略比较复杂花了很多时间，很多时间都在了解他的调度策略到底是什么，吾日三（三：多次，高三的拿笔记一下，高考要考的）省吾身，捎带否？同质否？到底是捎带还是同质？输出顺序对不对？那怎么实现啊？

　　这次的ALS电梯比上次的stupid电梯的改动主要在于调度器的策略，调度策引入了主请求跟副请求的概念。所以请求的处理分为以下几个部分：

　　1.主请求的选取（实现麻烦，暴力遍历，要考虑捎带的ER请求）

　　2.主请求的运行（因为我的运行方式是按楼层一楼一楼的运行，从开始楼层到目标楼层）（实现麻烦，还要特判开始楼层没有捎带只有同质）

　　3.副请求的捎带（每运行到一个楼层的时候都要判断有没有到该楼层的捎带）（实现麻烦）

　　4..副请求的同质（实现巨麻烦，因为捎带和同质判断的时间点是不同的，捎带的时间段截止在开门之间，同质时间的判断是在关门包括关门的瞬间）

　　5.一个主请求的同质在目标楼层判断（实现麻烦）

　　看不懂以上过程也没关系，估计除了我没人能看懂。

　　可能输我的实现问题导致出现了很多特殊情况的特判，代码冗长难看。特别麻烦，也就说我的调度器类相当于教材中调度器与电梯类功能的结合，所以我尝试在最近将我的代码改一下，不然感觉多线程要凉。但是改的话会面临很多的问题，因为我的请求是在边运行边进行请求的分析的，所以很难把这两个部分分开。可能再以后参考一下课上给出的类图，看能不能抢救一波。

　　看一下类图

　　

 可以看出来控制器十分臃肿肥胖。再看看代码的分析

心得体会的分享：

　　1.开始写之前最好仔细的理解提议，并构思实现的过程，

---恢复内容结束---

经过OO的前三周课程，对java程序设计语言有了基本的了解，可以算作是基本的入门吧。

第一次作业：多项式加法

目的：熟悉java编程语言，体会过程式编程与面向对象编程的区别，了解正则表的基本使用

第一次作业要求使用C语言跟java两种语言一起实现。对于C语言最主要的流程是字符串的处理，转换为桶存的多项式，进行加减运算最后进行结果的输出。

其中最麻烦的部分是C语言的字符串处理部分，我采用的是有限状态机的方式处理，过程及其复杂麻烦，很容易出错，就连OO作业也逃不过28定理。其余的部分实现较为容易。

在使用java编程的时候，整个任务由两个部分构成，一是多项式部分，主要负责多项式格式的检查，并进行系数的提取。另一个类主要负责多项式的计算。

多项式部分：

　　多项式格式检查部分采用的是正则表达式，比C语言简单很多，语法需要一定时间的学习，以及尝试。格式检查完之后就采用正则表达式的捕获组进行多项式系数的提取。加入待计算的多项式队列。

　　多项式还有一个计算的方法（由于多项式的构造方法不同，我只有加法），负责多项式之间的运算。　　

　　多项式还有一个展示的方法，负责多项式结果的展示。

多项式计算部分：

　　字符串的输入

　　字符串的分割（正则表达式爆栈）

　　计算的流程，遍历多项式的列表进行运算。

遇到的难点及问题：

　　1.正则表达式的使用，因为一开始不太会正则表达式，所以匹配格式的时候会出现很多的问题。

　　2.正则表达式的爆栈处理，当需要匹配的字符串过大，会导致爆栈。关于爆栈的原因，进行了简单的了解。正则表达式匹配的引擎分两种——DFA与NFA，其中一个区别是他们的可回溯性，NFA是可回溯的（java等多种语言默认），DFA是不回溯的，所以其匹配的速度很快，但其功能性不如NFA。关于其匹配的原理请移步至   https://sine-x.com/regexp-1/

我作业中出现的bug：

　　1.使用输出中间结果的匹配方法，在de完bug之后忘了删除。以后就更加细心一点（其实是不太会调试，只能System.out.println，但现在不一样了，翻身农奴做主人）。

　　2.由于正则表达式爆栈，导致的bug，将要匹配的字符串分为多个短的字符串放入匹配，放入的标志是检查是否有“}”，但是这种方式出现了很对问题，{（1,3）能正常判错，但{（1,3）}+@，对于这种就失效，因为找到{（1,3）}后放入，而+@不会检查，所以会出现问题，但这样的bug很难发现。应该在最后判断是否到了字符串的尾，这个bug是在我测试别人作业发现的，幸好测我那个人没有发现。

对方作业中的bug：

　　按照错误分支树进行测试，没出现什么bug，但是对于极端的情况，比如“{}”作为输入，就会判错，对于这一类极端的情况很难考虑到，需要有扣分的决心才能找到。

类的分析：

　　这次实验较为简单，类的构成也比较标准，故不在此赘述，类图如下：

 

 

　　

　　这也算是对面向对象编程的基本入门。

第二次作业：实现傻瓜电梯（stupid elevater）。

　　遇到这个作业的时候，构思大概就是跟第一次作业差不多，第一部分是电梯的处理，过程跟第一次作业类似。这个请求的处理包括三个部分，一是电梯类，二是楼层类，三是请求类。电梯类主要处理电梯的请求，楼层类处理楼层的请求，处理完请求之后统一作为请求类存在于请求队列之中。然后由调度器类实现电梯的运行并将结果进行输出。

　　请求处理过程在此不再赘述（读者自己脑补），主要讲电梯的运行过程，由调度器负责实行。

　　调度器类：

　　每一次将请求队列中的一个请求进行答复。当电梯运行完一条指令之后。会根据电梯目前的运行状态跟后续的指令进行处理，判断同质请求等，并进行同质请求的输出。

　　此次作业比较简单，所以其实很多类都会显得十分的冗余。自己在写的过程中都觉得很多类都可以省去，没按照教学的方法写，以至于后来的ALS的电梯实现会比较困难与累赘。此次作业的类图如下。

　　从类图可以看出，结构还是比较清晰的，但是显得过程比较冗余，对于请求处理的部分完全可以用一个请求类代替，这样再需要一个调度器类进行结果运行就好了（仅仅是个人看法，其他类完全是尸位素餐）。

难点分析：

　　最主要的问题是同质的判断，我的方法是完成一个请求之后，遍历后面请求（请求发出时间小于等于该请求结束）。

bug：

　　此次作业出错的地方不多，但是在查bug的时候发现，有一个人因为没加#，错了一半多，功能完全正确，看着特别心疼，算是杀鸡儆猴吧。

第三次作业：ALS电梯

　　这次的电梯的调度策略比较复杂花了很多时间，很多时间都在了解他的调度策略到底是什么，吾日三（三：多次，高三的拿笔记一下，高考要考的）省吾身，捎带否？同质否？到底是捎带还是同质？输出顺序对不对？那怎么实现啊？

　　这次的ALS电梯比上次的stupid电梯的改动主要在于调度器的策略，调度策引入了主请求跟副请求的概念。所以请求的处理分为以下几个部分：

　　1.主请求的选取（实现麻烦，暴力遍历，要考虑捎带的ER请求）

　　2.主请求的运行（因为我的运行方式是按楼层一楼一楼的运行，从开始楼层到目标楼层）（实现麻烦，还要特判开始楼层没有捎带只有同质）

　　3.副请求的捎带（每运行到一个楼层的时候都要判断有没有到该楼层的捎带）（实现麻烦）

　　4..副请求的同质（实现巨麻烦，因为捎带和同质判断的时间点是不同的，捎带的时间段截止在开门之间，同质时间的判断是在关门包括关门的瞬间）

　　5.一个主请求的同质在目标楼层判断（实现麻烦）

　　看不懂以上过程也没关系，估计除了我没人能看懂，因为写的太糟糕了，望多多包涵。

　　可能输我的实现问题导致出现了很多特殊情况的特判，代码冗长难看。特别麻烦，也就说我的调度器类相当于教材中调度器与电梯类功能的结合，所以我尝试在最近将我的代码改一下，不然感觉多线程要凉。但是改的话会面临很多的问题，因为我的请求是在边运行边进行请求的分析的，所以很难把这两个部分分开。可能再以后参考一下课上给出的类图，看能不能抢救一波。

　　看一下类图

　　

 可以看出来控制器十分臃肿肥胖。再看看代码的分析

可以看出来我的调度器类的圈复杂度太高了10.5，这个太高说明代码质量特别低，而且难以维护，自己也有真切的体会，觉得十分麻烦，是自己的功能没有构思得太好，schedule类的功能太复杂，尤其是捎带和同质判断部分，这个部分是最难处理的，所以写得比较多，if的嵌套语句太多，应该好好的构思一下实现的功能再去实现。另一方面schedule类的功能太多了，每一个功能的代码量及其巨大，导致它的代码长度也最长，最难以理解，以后在写得时候应该把功能细分，代码量跟条理很更加的清晰，以后会加油改进的，希望自己以后能够注意吧，算是给大家一个忠告吧，是自己写作业太着急了，要改掉拖延这个坏习惯，希望大家引以为戒（这也算是杀鸡儆猴吧）。

心得体会的分享：

　　1.开始写之前最好仔细的理解题意，并构思实现的过程，把实现的功能想好了之后，再开始写，每个类实现的功能不要太杂，条理一定要清晰，如果发现自己没考虑到的情况还可以再加一些东西，也不会显得太复杂，我这个也就当一个反面教材了。

　　2.一定要留出充足的时间写作业，不一定要非得马上动手开始写，可以先构思，不要赶ddl，不要赶ddl，不要赶ddl，重要的事情说三（多次）遍。至少要花一天的时间测自己的bug跟写说明文档。

　　3.最后是对大家跟自己的祝愿吧，希望自己从OO中获得的不仅是学会用java编程，更多的是学会如何写出代码质量高，规范，可维护性，鲁棒性好的程序，学会一些编程的技巧，向着一个真正的程序员进发。也希望大家能在OO中有所收获，大家加油 (ง •̀-•́)ง！