2019年北航OO第一次博客总结

 1、基于度量对程序结构的分析

1. 第一次做业

1.1 基于类的分析的度量

首先，基于类的属性个数，方法个数，每一个方法的规模，每一个方法的控制分支数目，类总代码规模等特征对本次做业的结构进行分析。

1.2 基于类间内聚和耦合的度量

我使用了MetricsReloaded插件来对代码的复杂度进行了分析。

还有对于方法的复杂度分析因为篇幅缘由没有贴出来，主要的指标为ev,iv,v三个指标，分别表明基本复杂度、模块设计复杂度以及模块断定结构复杂度，ev大表明代码非结构化程度高，难以模块化和维护。iv大表明模块间耦合度高，模块间难以隔离与复用，v大表示代码独立路径条数多，难于测试和维护。在作面向对象度量时，咱们常常采用ck度量(Chidamber Kemerer)来度量耦合，内聚，封装等等特征。上表中wmc表明的是类的方法权重，表示一个类中全部方法的复杂度之和。显然越大说明越复杂。

1.3 UML图及结构点评

因为是第一次做业，所以对于面向对象的思想还不是特别熟悉，我此次将main类与Poly类写到了一块儿，其实应该分离，一个多项式的类，一个项的类，一个main入口类。总体来说结构不是很好，并且有两个比较长的方法同时分支较多，同时也就形成了它们的独立路径数较多，模块复杂度较高。

2. 第二次做业

2.1 基于类的分析的度量

2.2 基于类间内聚和耦合的度量

个人高复杂度方法体如今输入处理，输出处理以及化简上，此次做业如何有效的化简是一个难点。

2.3 UML图及结构点评

本次做业的设计较为体现了面向对象的思想，设计了一个main入口类，多项式类，项类，因子类，以及其中因为因子是由底数和指数组成的，而指数又有多种形式，故设计了一个底数的抽象类base，将常数类const,幂函数类power，三角函数类triangle做为了base的子类，这样就能够将一个多项式一点点解析成项，因子，底数，指数等等。同时，因为每个类都有共同的特色就是可求导，所以我设计了一个求导的接口Derivable,全部的类都实现了这个接口，这符合了java面向接口编程的思想，同时也提高了代码的规范性。

3. 第三次做业

3.1 基于类的分析的度量

3.2 基于类间内聚和耦合的度量

 

发现个人高复杂度的方法所有都是对于输入处理上，因而可知个人输入处理的不太好，写的十分面向过程且十分容易出错。

3.3 UML图及结构点评

本次做业的架构和上一次做业是彻底一致的，由于上次做业时我就考虑到了程序可扩展性的特色。然而本次做业在加了表达式因子和嵌套因子后显得这个架构有一些问题。求导部分利用递归向下求导的方式却是不难实现，这次做业最难的输入部分我处理的不是很好。此次输入的难点主要是出现了表达式因子和嵌套，咱们如何用正则表达式来正确的识别和解析。个人想法是先找到全部非三角函数括号中最内层的括号，将其解析为一个多项式，这时再解析出该多项式内部的三角函数，把三角函数括号中嵌套的多项式因子解析到三角函数的属性中去，重复这个步骤直到没有括号为止。整个过程虽然能够实现可是十分复杂，十分面向过程且会有多分支，行数很是多的方法，复杂的正则表达式的存在。后来在讨论课上据说的用工厂模式或一个parser的类能够更好的实现该输入解析过程，parser类里面分别有对poly,item,factor的解析方法，高内聚低耦合避免了一大串if-else的出现。

2、Bug分析

1. 第一次做业

第一次做业个人强测没有出现WA的状况，可是被hack了12次(2同质)，分别是\\s+匹配到\t和空格外的字符的状况、以及直接输入空格程序crash的状况，程序crash的缘由是我在获得字符串以后直接进行了input.trim()操做，致使输入input变为空串程序crash，有两种更改方式，一种是直接把main方法里面的全部内容用try-catch保住，确保程序不会出现crash(这也是我后面两次做业的写法)，另外一种方法是在trim()后面再判断一次串是否为空。对于另一个bug，个人正则里面写的是[ \\t]*然而仍是出现了bug，这与我程序的设计结构密切相关，由于我再刚刚读入input的时候就用trim()去掉了两边的空白符，这样致使输入字符串两边的\v和\f没法有效的识别WF，形成了bug的出现。个人修改方式是先看全部的输入字符是否有非法字符，若是有的话直接输出WF便可。

2. 第二次做业

第一次做业个人强测没有出现WA的状况，可是也被hack了3次(2同质)，分别是在输入符号处理中的if表达式中的||手误写成了&&，和对于输入错误的匹配没有识别出WF。仔细想一想，这与个人设计结构也有着千丝万缕的联系。我对于输入的处理是在去掉了输入两边的空白字符后依据此时input.CharAt(0)来肯定在前面添加"+"或者"+0",然而我没考虑到*x若在前面"+0"会形成原本是WF的数据变成合法，所以致使了bug。另一个bug就是典型的一大段if-else形成的键盘误操做，这也体现了减小分支数量下降代码复杂度的必要性。

3. 第三次做业

第三次做业个人强测WA两个点，被hack了10次(强互测加起来2同质)，分别是输入匹配时正则表达式少了一个[ \\t]*形成的有空格致使不匹配以及一个符号出现了问题。这两个问题的产生就与个人设计很是密切的相关了。我写了4个正则，其中最大的正则有6行，如此长的正则不免会不当心失误，写小正则把问题分开分析是避免这类错误的一个很好的方式。而另一个符号错误则彻底是因为个人输入写得太过复杂，括号来回匹配的逻辑，好比解析一个item，会返回一个poly.解析一个factor也会返回poly，而每一个item都有其固定的符号,此次Bug的出现就是由于在解析item返回poly的时候没有考虑原来item的符号，而默认"+"形成了错误。因而可知，面向对象的设计模式，封装的好处就是减小耦合，减小出错点。

3、Hack策略

1. WF

前两次做业错误主要集中在WF上，这时候就能够手动设计测试样例，好比全空格，空串，只输入常数，输入x^0，0*x，si n(x),sin   ( x    )，+++1，++ 1，\f\v，BigInteger,爆栈,......等等，由于前两次做业正确性的实现上并不难，主要你们的出错点在对WF的处理上，所以个人这种策略有效性也很高，前两次做业共提交7个测试样例hack18人次。

2. 正确性问题

第三次做业强调正确性的问题，我也从正确性的问题入手，具体方法就是对于指导书上对本次实验要求的全部功能，先分别构造测试数据，在将各类模式组合起来，好比sin()里面有表达式，里面还有嵌套的sin()，再加一些项乘起来之类的。覆盖全部的状况覆盖全部的功能就能找出bug。因为第三次做业你们基本都没怎么优化，因此直接看输出结果很难看出正误，所以能够把每位被测者的输出结果赋上一个x值(好比x=1.1)比较不一样被测者输出结果的值是否相等，若不相等显然是出现了问题。

3. 根据程序找bug

这种方法难度较大，主要缘由是部分代码可读性较差，结构不清晰，等等。固然若是能看懂对方程序的话确定是更容易从根源处找到bug。经过白盒测试，对复杂的类进行单元测试来寻找bug。

4、Applying Creational Pattern

1. 工厂模式

工厂模式(Factory Pattern)是Java中最经常使用的设计模式之一,这种类型的设计模式属于建立型模式，它提供了一种建立对象的最佳方式。在工厂模式中，咱们在建立对象时不会对客户端暴露建立逻辑，而且是经过使用一个共同的接口来指向新建立的对象。所以，对于本次做业可使用工厂模式来建立表达式，项，因子，咱们只需定义一个建立对象的接口，让实现了该接口的子类本身决定实例化哪个工厂类。在咱们明确地计划不一样条件下建立不一样实例时，工厂模式将十分管用。

2. 抽象工厂

抽象工厂模式(Abstract Factory Pattern)是围绕一个超级工厂建立其余工厂。超级工厂又称为其余工厂的工厂,在抽象工厂模式中，接口是负责建立一个相关对象的工厂，不须要显式指定它们的类。每一个生成的工厂都能按照工厂模式提供对象。系统的产品有多于一个的产品族，而系统只消费其中某一族的产品时，可使用抽象工厂做为全部工厂的抽象父类，这样咱们就不用花费时间在选择接口上了。

5、总结与展望

1. 总结

4周时间过去了，OO也过去了第一单元，早就据说了OO的恐怖，现在也确实是体验了一番。整体来说第一单元的学习还算满意，测试方面仍需增强，另外就是面向对象的思想还需不断的培养。第一单元其实主要仍是java的入门，帮助咱们更加熟悉java的使用。还有就是感受今年的OO确实感受要比往届好了很多，公测分占主要的状况下大致上保证了课程的公平，分ABC组互测也避免了一些悲惨的状况，整体来说OO课在不断变好，在此感谢助教和老师的付出！

2. 展望

前路漫漫，道阻且长。后面还有多线程等等很难的知识和做业在等着咱们，但愿咱们能继续努力，在本学期结束时能真正有很大的收获。