OO第一次博客作业
写在前面
倘如有的同学在安装metrics插件时遇到了下载断开等困难
CHH同学为我提供了如下解决方法：
可以从这里下载压缩包https://pan.baidu.com/s/110Paad1AlbG6xMRa1FVnRg
解压后将两个文件夹复制粘贴到eclipse安装路径进行替换
然后在package explorer视图右键项目文件夹选择properties把metrics打上勾就可以使用了
第一次作业
一、度量分析
通过分析metrics图可以发现自己在方法set_Poly()上的圈复杂度过高，块嵌套也过高，也就是里面还有太多且过深的条件判断语句。主要是因为在第一次程序设计时贪图省事直接复制了C语言写好的代码，这个方法主要是将格式正确的字符串转换成各项信息，但是由于使用的是逐个字符读取，其中的条件判断格外多，尤其是在所输入的多项式复杂时，这个方法效率极低，设计时没有考虑到，现在回过头来反思觉得这个问题可以被更好解决，例如使用split分割每个项再利用parseint等方法就可以轻松得到所需信息，这一点上确实考虑不周，徒增了过多代码。同时这一点也希望能给予同学们警示，在条件判断时建议仔细思考哪些是必要的，哪些是可以简化的。大段嵌套的if-else语句只会增加后期阅读修改debug的难度。
二、类图
在类的设计上我这次设计的比较简单。Reader类用来读取并初步处理字符串，读入并剔除格式错误的字符串。Poly类仅用来存储每个项的信息并拥有计算方法。ComputePoly类作为主类负责调用其他类，耦合度较低，独立性较高，设计还算简练。
三、BUG方面
第一次的程序被查出了一个bug，是因为我在设计上犯了错误，当时考虑到输入最多只能为999999，为了标记那些项已经被记录过，将每个项的系数都设为了1000000，这样就可以避免输入相同{(0,5),(0,5)}这种阶重复的情况，本来应当在计算是忽略系数是1000000的项，结果我却写在了输出时判断，导致对于{(1,7)}+{(999999,7)}这种计算我并不会输出阶为7的项，是很低级的错误，说明在编写代码的过程中，切记想一出是一出，局部解决问题是不够的，要考虑到特殊样例，以及在全局应用上会不会出现问题。
在查别人bug的时候主要应用的策略是针对指导书创造小样例，对于指导书中每一个小条件独立的测试，利用这个方法我查到了被测人两个bug，分别是多项式和项个数超标的问题。我的被测人代码偏向面对过程，是一个利用了有限状态机的读入程序，基本上就是一个主函数到底，虽然在功能上没有问题，但是还是觉得这个课程尽量采用面向对象的思想。阅读代码后没有发现别的什么问题。测了几组随机大样例也没有发现问题便作罢。
第二次作业
一、度量分析
这次的metrics图就比第一次作业看起来舒服一些，通过回去阅读所写的代码我发现，导致这次程序复杂度降低的原因主要是通过阅读指导书和上课时老师讲授的ppt，合理规划了一个电梯程序所需要的各个类，将所做的工作进行分配和规划，不让某一个类负担不应属于自己的工作，也不要让其中的某一项工作过重。
二、类图
我认为本次的类设计上比较符合要求，通过scheduler类来调度elevator从请求队列取出请求进行处理，但是本次设计上仍然存在问题。
1、为了尽可能贴近面向对象的思想，我把请求的提出方法分别在电梯和楼层类中定义，企图用这种方法让请求更像是电梯或楼层提出的，但是这导致了两个类中一部分代码的重复，代码复用性不好，后来再看也觉得这种设计比较累赘。
2、请求队列的实现上本来想使用arraylist，但是在编写前想到自己对arraylist的方法了解不多，完全可以通过数组和定义相关方法来自己实现，方法比较少可以降低错误率，这一点上其实我也说不清楚到底是好是坏，但是在代码行数上的确有了增加。
通过类图可以发现，这次设计各个类分工还算明确，但是在方法上定义过多，不应该为每个类的内部属性都定义get-set方法，要考虑到程序的应用情况。
三、BUG方面
这次作业并没有被查出bug，但是并不代表本次作业没有问题，第一个是前文提到的在某些类上设计过于臃肿，第二个是我是使用了部分try-catch，这个如果测试者自己观察是可以发现的，但是由于没有套try-catch的部分并不能想出来什么崩溃的可能，但是为了以防万一，建议大家在设计上仍然要考虑周全。
在测试别人程序时，仍然使用了各个情况单独测小样例，然后跑随机大样例的方法，被测人的程序写的也的确很优美，阅读代码后发现吸取了其去除同质请求的方法，通过预测结束时间，扫描队列直接去除后面的请求，而我使用的是记录每个按键的灭灯时间，在读取到请求是进行比对，变相的空间换时间，但是需要实时更新时间，并且在后面的作业上处理捎带有些麻烦，所以在后面进行了更改，通过比对互相的代码体会实现功能的不同方法，这个可以说是我从别人代码中获取最大的收获。
第三次作业
一、度量分析
通过分析metrics图可以发现，在学会使用本工具前，笔者仍然存在着圈复杂度过高，块嵌套过深的问题，在以后的编程过程中会多加注意。第三次作业中主要编程不合理的是command()方法，本来设计是想利用这个额方法处理请求，但是顺着思路写的时候把输出结果写在这一个方法里面了，甚至包括了输出的排序（在同时完成多个请求的情况下），导致使用了过多的if-else判断和嵌套，现在反思应当单独编写输出方法，通过传参数来输出不同结果，将这部分分离出来，降低圈复杂度，应当会使代码结构好很多。至于块嵌套深度部分，请求队列类中由于是自己编写的add()方法，所以在实现上用了比较多的if-else，将会在下次作业中改写为arraylist，同样的问题也在一个名为findbest()方法中，这个在设计时是为了寻找到主请求路径上最好的捎带进行执行，代码编写时条件可以进行合并和缩减，当时并没有考虑到，经过度量分析就很明晰的显示出来了，这也给了我一个启示，条件判断不光要思路清晰明确，也要考虑嵌套深度和比较次数，否则代码冗长啰嗦，不易修改和阅读。
二、类图
本次的类图相比较上次的主要是编写了elevator接口，并且新写了scheduler类进行了继承和方法重写，但是其他的类基本没有改变，所以上一次作业所存在的代码复用性差，重复性高的问题依然存在。并且还有一个问题就是对toString()方法理解不到位，在最后才考虑着重写这个方法，导致在该方法的使用上有一些为了使用而使用的痕迹，这点应该在程序设计开端就进行考虑。
三、BUG方面
第三次作业并没有查到bug或者被查到bug，使用的策略依然是单独用小样例测单个情况，再使用大样例跑程序和别人的结果利用python对拍，这里主要是修改了被测人的代码，跑了3w和5w条指令的程序，希望能以这种方式发现问题所在，然后再回归程序寻找问题的具体原因。在自己的debug过程中一度陷入了心态崩了的情况，一个样例刚调好，更新的代码又出现了新的问题，一个又一个的打补丁，这时候应该通读一下自己的代码逻辑，在逻辑没有问题的情况下再逐步检查每个方法的细节，结合单步调试和输出调试，总能发现问题所在。
心得体会
1、首先是觉得自己的确在慢慢体会面向对象的过程中，从程序设计开始，先思考需要什么对象，他需要什么功能，而我只需要一个框架，然后交给对象做就可以了，这个过程我认为在程序设计上有利于全局的审视整个程序的形成过程，同样在遇到问题时也易于定位修改。
2、在调试程序的过程中学会使用了eclipse的单步调试，在面对电梯的输出时常常面对从某一行突然就不一样了，需要用单步调试查看各个变量的变化情况，很容易就能定位到错误位置。同时结合输出调试可以更加快捷的debug。
3、写程序一定不要着急，包括指导书的阅读，好的理解和思路对于程序设计事半功倍。
4、初次接触面向对象编程和java语言，需要学习的还很多，这几次作业学习并实践了正则表达式、接口、继承、try-catch、this关键字、动态数组、对象相等和状态相等的关系、属性可视性（public、private、protected）等知识，希望能在之后的学习实践中多多回顾应用。
5、一点小建议，博客的撰写可否分成几次小的部分放置于每次作业之后，目前总结1-3次作业发现了很多共有的问题，想必更早的总结能为后面的工作提供前车之鉴。
6、对自己的希望，能够在搭框架的过程中思路更加明确，用好接口、继承，要知道只有在实际中使用到了，这些特性才算是有用的。
