面向对象三次做业的总结

第一次做业：

Metrics度量分析

博主第一次面向对象的java代码分析：第一次做业的目的是由面向过程到面向对象过渡，了解二者之间的区别。因为第一次写面向对象的代码，不免会有面向过程的习惯，正若有些同窗调侃道：伪装面向对象。博主的第一次做业的代码中也能明显看到过程化编程的痕迹，好比关于输入内容的处理，判断与转化，这部分功能我直接在main函数中用了过程化编程实现，没有封装成一个单独的类，。其余的功能的实现，我参考了老师ppt上给出的结构样例及方法，所以看起来像面向对象。第一次做业我有11个bug,准确来讲是两个bug;第一个bug:正则表达式匹配时爆栈了，虽然写代码的时候知道有这个bug,可是无奈正则表达式不熟悉，并且写了一天代码没吃饭饿晕了，不想写了。另外10个bug,也就是第二个bug:输入格式错误要输出"ERROR",结果我有一个地方把"ERROR"写成了"ERROE",碰巧那个地方在个人设计思路里是匹配较多格式错误的输出，就莫名多了10个bug。Mtrics数据分析中标红的部分应该深度分析方面有点问题，本人设计思路方面属于比较求稳，面面俱到，宁肯重复，也不漏掉一种可能状况，所以形成了循环和嵌套得比较多。接下来的两次做业也是属于循环嵌套比较多。分配给个人测试代码是个大佬的，找不出错误；

博主第二次做业的java代码分析：设计思路：先将全部的指令输入进行处理，包括判断，转化，生成相应的电梯指令，并将生成的电梯指令加入到指令数组中，而后经过schedule类进行统一处理并输出结果。因为指导书的硬性要求，必需要有5个类，博主各个类的功能方法看起来也还算比较分布均匀，固然，有了第一次做业的心得，我增长了一个Judge来专门处理输入，判断和转换问题。第二次做业刚完成的时候判断部分有些冗余，重复代码行比较多，删减了大约100行，主要是思路不清，考虑不全。细看博主的代码结构，能够发现，方法中set,get方法占了很大的比重，各个类的属性虽然定义为了private,但更改仍是主要在其余类里面进行，自闭性不强。因为第二次做业考虑周到，所以第二次做业没有bug,分配给个人测试代码又是一个大佬的，没找到bug.

博主第三次做业代码分析：代码思路和第二次的相同。先写点内心体会吧，前两次的指导书看完了基本就能有思路了，总体架构可以出来，须要作的就是一些细节方面的理解和补充，第三次的指导书我看一天还不知道怎么动笔，而后是边想边写。固然最后仍是勉强把架构搭起来了，相比于第二次的代码，我第三次只改了两个类，一个是电梯类，一个是添加了schedule的子类son。这两个类是大象类，电梯类属性多，set,get方法多，son类的run方法足足有300行，没办法，虽然丑点，总比写不出要强点。电梯类冗余主要是由于第二次做业的属性定义不敢去更改（构造电梯有效指令的功能里用到了原来的属性，而电梯指令构造方法没有作改动），只能定义更多的其余属性来记录相关的状态和标记；说实话，ALS电梯调度真的有点复杂，考虑到的状况有限，到后来写完了拿别人的数据一测就能发现很多bug,因此son的run方法里面电梯调度方案增长了一些针对调试中发现的bug而作出的补丁代码，显得有些无序。因为我测试代码没按照给出的分支树构造，所以漏掉了要考虑的状况，另外，发现的bug也并无所有调试出来，有一个bug我调试了改了整整一天也没有改过来，看来是改不出了，主要是一个标志物的值在某条不相干的指令执行后居然改变了，致使后来的指令判断发生错误，为了下一次的多线程，我仍是得从新写run方法。这一次个人代码有两个bug,一个是输出顺序没彻底弄清楚，致使顺序错误，第二个就是我改了一天都没改出来的bug。感受第三次指导书仍是有点问题，对同质请求，知足捎带条件的请求的举例不够多，大多数的状况都得从issues和助教口中亲口得到，或许是我我的的理解能力不行吧。另外，本人的设计思路比较传统，因为某条输入时间靠前的指令居然可能被输入时间靠后的指令所携带，因此我用了三层for循环，也是够拼的，还好只须要处理100条指令，不然我都要考虑运行时间内能不能有结果。总之，就是个人设计方面应该改进并优化一下。我测的代码仍是个大佬的，又是零错误（我要得负分了，笑哭.jpg）。麻烦下次给我一个有错误的代码，最起码别让我负分。

心得体会：

1：不要把多个类写在一个class里面，调试起来会很痛苦（尤为是像我这种只会System.out调试的人），代码写到1000行的时候，上下翻看都困难。

2：不要急着动手，想得越清楚，理解得越透彻，写出的代码结构更严谨，须要更改的地方就少。