OO第一次博客总结

OO第一次博客总结

　　大一就久仰OO大名。曾经有一份真挚的JAVA课放在个人面前，我没有好好的珍惜，等到OO到来后，我才追悔莫及。人世间最痛苦的事莫过于此……如今来分析一下本身的代码和心得，总结一下一个月来的收获。

• 第一次做业

　　难点分析

　　第一次做业的要求是实现有必定鲁棒性的多项式加减法，C语言代码你们都练习过，所以算法部分其实并不是难点。对于大多数刚开始接触JAVA语言和OO思想的同窗来讲，此次的难点主要是：JAVA语法、面向对象思想、正则表达式的使用和程序的鲁棒性。对于前二者，其实大一的python曾练习过面向对象的思想，但当要求写一个面向对象的程序时，我眉头一皱，发现事情并不简单。看了不少遍课件，与不少的人讨论，我也只是明白了什么是一个“面向对象的格式”。回看这三次的做业，都存在着某个类150+行的现象，实际上仍是面向过程的。想理解怎么写才是OO的，我推荐你们仍是要多看别人的代码，可能初始阶段会很艰难，好比我在第二次互测时拿到的代码有23个类……可是若是坚持看懂，必定是颇有收获的。正则表达式是一个便利的工具，但也存在必定问题，先按下不表。而程序的正确性以及如何保证不crash，就须要大量的测试验证了。本身测得不够全面，就极可能被别人看到代码后，“量身定制”bug。

　　在设计上，我采用了一个Poly类型的数组Polylist来存放各个合法多项式，最后将数组的每一项和一个空多项式相加便可。坑在于如何判断输入时出现{（0，1），（0，1）}为非法。该输入系数均为0，若将多项式系数初始值设为0，将没法判断此输入因指数重复而非法。解决办法之一是对每一个指数开一个数组，存储其是否被输入过。然而更好的办法是将系数初始值设为输入系数的上限，在最后相加时，对于系数为上限的项不予相加。

 

　　类图和度量分析

 

 

　　能够看到，get_Poly方法的McCabe Cyclomatic Complexity和Nested Block Depth因超出范围而标红了。McCabe Cyclomatic Complexity（圈复杂度）用来衡量一个模块的复杂程度，统计一个函数有多少个分支(if,while,for等)，没有的话复杂度为一，每增长一个分支复杂度加一。圈复杂度的做者McCabe认为，圈复杂度在3~7为比较好的结构化方法，圈复杂度大说明程序代码可能质量低且难于测试和维护。Nested Block Depth（块嵌套深度）则为嵌套深度。这两块出现超标，每每说明程序设计有缺陷，或部分代码嵌套深，难以判断逻辑，或直接写成了面向过程的思想。这个get_Poly方法内容以下：

 

 

 　　这个方法嵌套十分严重。除判断错误输入较多外，不只多余的判断了是否有异常字符，在切分多项式时，更是用了贼蠢的遍历手动切分（手动切分也能够写的更简单吧），切分后更是直接扔掉，待存储多项式时候从新遍历。其实第一次写的时候，只用一个正则表达式匹配整个输入，比上述代码简单太多，无奈测试时发现，当输入过于复杂，正则表达式自身会引起crash，在判断为正则表达式自身的限制以后，无奈将匹配改成屡次匹配。代码也所以长了许多，同时给debug产生了很大的难度，更是下降了代码的可读性，一层一层的嵌套着实使人难以读懂。但这样写也有必定的优势。频繁判断能保证错误输入时尽快结束，防止恶意输入时程序耗时过长（但实际上我判断的确实过于频繁了，增长了嵌套深度）。

 

　　测试分析

　　因测试较为全面，并未出现bug。而我拿到的程序中，公测和互测的错误都是如未说明输入“{}”的处理方式等Readme的错误。Readme做为程序使用的指导说明，必定要考虑到全部边界状况，不然使用者仅根据本身的理解，极可能出现误差。而事实上，程序出现bug，大多数时候也就是在这些边界状况上。在测试时，除了少许功能性测试外，大量的精力花在了特殊状况、边界状况、超长输入上（如一条大小为1M的txt输入数据）。

 

• 第二次做业

　　难点分析

　　傻瓜电梯的设计与验证。傻瓜电梯的难点，应是对电梯的设计上，即如何实现电梯、分别给五个或者更多的类什么功能、各个类之间如何串联等问题上。我采用了三个double类型数组，分别存放ER、FR_UP、FR_DOWN每一层的按钮灯熄灭时间，当指令输入时间小于等于对应按钮熄灭时间则断定其同质。而电梯类elevator则存储电梯在该指令执行完成后的时间、楼层、运动状态，以供给调度器计算指令完成时间。对于指令队列，从头开始逐条取出处理。

 

　　类图和度量分析

　　此次标红的一样是圈复杂度和块嵌套深度，出现问题的方法除了和第一次做业相似的read模块，用于识别合法性外，还多了一个schedule方法。这个方法仅仅用于输出正确结果，但因当时考虑不周，分了指令为ER、FR_UP、FR_DOWN和电梯为运动或静止，共6种状况，过度冗余，实际上一次就能够说清。所以就不放代码了，并不是难以改正的设计缺陷。可是能够看到，floor类和其余类并没有链接，由于个人floor类是空的……设计上没有用到floor类，也就使得其余类的代码行数开始增长。看似不影响，实际上给第三次埋了一个坑。虽然更加OO了一点，可是从类之间的链接数量就能够发现，实际上仍是不清楚究竟什么样的代码是面向过程的，从实质上来看，此次做业依然是OO壳子下的面向过程代码。

 

　　测试分析

　　本次做业相较上次，输入更加复杂，所以在功能性测试和边界测试、压力测试之外，加入了随机生成输入以进行测试。由于测试比较全面，一样没有bug，不过我拿到的代码不只很是工程化，javadoc写的也很是官方，23个类真的厉害……此处不作分析，类图就不作整理了，搬运在下面了。也有同窗开始时使用时间做为程序的条件，即每0.5秒取一次指令，这样大大下降了程序的运行速度，恐怕更没法经过10s的时间限制。

 

• 第三次做业

　　难点分析

　　ALS电梯。此次电梯的最大改进为容许捎带，这就出现了主指令和最多两条捎带指令（即若存在捎带，能找到一条最早捎带的指令，以及可能会找到一条和它仅指令标识符不一样的指令一块儿被捎带）。所以排在后面的指令有可能被先完成，不能从队列头开始向后遍历。我使用了一个指令队列，规定头指令为主指令，判断同质后，向后找最优捎带指令，执行后从指令队列中删除。当全部比主指令先执行完的捎带指令所有完成，执行主指令并从队列删除，将新的主指令置顶。循环下去至队列为空。然而在完成代码的时候，没有思考好捎带的边界条件和更新熄灭灯的时刻，使得判断捎带和同质时存在问题。此外，要求使用的继承、接口、重写也是新的难点。

 

　　类图和度量分析

　　

　　对于圈复杂度和块嵌套深度的问题，因为基本沿用了第二次做业，不作赘述。惭愧的是，虽然要求使用继承，因为第二次做业中schedule没有分到elevator和floor的部分，致使该类其实只有一个行为，在子类中还被重写了……实际并未用到继承的思想。

 

　　测试分析

　　此次测试水平又进步了……经过两个编译生成的.class文件和随机测试数据，能够在python程序中实现自动运行和比对结果。本次的测试重点是捎带请求和同质判断。捎带又存在功能性测试和开关门时的边界测试。而同质则要考虑到新加入的捎带请求是否为同质，又是否利用捎带请求信息更新了熄灭灯数组的时间。我本身就出现了判断捎带未注意边界条件的状况，也所以影响了灯熄灭数组的更新，使得判断同质出现了问题。此外，两次做业中schedule类明显过长，成为一个“万能”的类，是不符合面向对象思想的。也致使了这个方法过于复杂，我通宵都没能de完全部bug。

 

 

• 心得体会

　　关于设计和debug的体会，上文已叙。但经过读手中拿到的代码，让我意识到了dalao的代码水平是什么样的。但能读到的代码只有一份，对于你们理解面向对象思想十分有限，但愿能在讲做业的过程当中增长一下各类思路的介绍，能给你们带来更快的进步。