OO第一单元学习总结

一. 基于度量分析程序结构

• 第一次作业

UML类图：

方法复杂度：

 

　　在第一次作业中，面向对象的意识不足够，没有理解应该依据什么创建类，除了主类以外只新建了一个可有可无的De类，由此也导致了代码长度和复杂度的失衡。在输出结果时通过一个逻辑和表达都复杂的out方法也体现了我的不熟练。

• 第二次作业

UML类图：

方法复杂度：

　　第二次作业大致延续了第一次作业的思路，建立TreeMap容器，将Key替换成新建的Keys类，Value仍为系数，由此将每一项都格式化，便于合并。额外增加Factory类（并未使用工厂模式，这个类只用来解析）、Func接口、Mult类、Add类，试图建立层次关系。但main、out的臃肿体现出了明显的过程化的思想，此外也有一些代码的重复。总体观察前两次作业，可扩展性大概就止步于此了，主题思想对嵌套是无能为力的，看来第三次作业的重构势在必行。

• 第三次作业

UML类图：

方法复杂度：

 

 （注：方法众多，这里只截取了情况格外糟糕的几个方法）

类复杂度：

　　第三次作业在第二次作业的基础上做了较大规模的重构。比较大的成果是，main方法变得十分清爽，解析、求导、输出每一步都很直观；将每一种函数、项、表达式分别创建类，共同实现求导接口，并运用各自法则，嵌套部分在三角函数内部实现。通过分析可以看出，判断合法性的Analyse类、解析输入的Factory类（仍非工厂类）和Produce类的情况不容乐观。Analyse内部有大量的函数调用和递归，用于判断嵌套，而且该类本身庞大至200行；Factory和Produce的内部方法则会相互调用、递归，而且还会调用Analyse的方法，这无疑是大大加深了耦合度。在求导方面，Deri方法的返回值我选择了ArrayList容器，与Mult和Add的构造方法参数相同，便于构造，但创建逻辑似乎有点绕。除此而外，虽然性能分所占比重不小，但我还是因为深感能力有限而将其放弃，为求稳妥保留了大量的括号。

---

 

二. 分析自己程序的bug

• 第二次作业的互测中，我被hack了一个点，原因是我并没有考虑到如果每一项（总项数>1）的系数都是0时，需要输出0，我的程序在此时会无输出。通过分析我认为这是由于该次作业结构中out方法逻辑复杂导致的考虑不周，这种多个if的设计应该避免。
• 第三次作业的强测中，我WA了两个点，都是因为没有成功判断WF导致的。我在解析表达式时，先排除一些能用简单的正则表达式查出来的格式错误，然后再直接删去空白字符。但由于指导书阅读的不仔细，没有注意到表达式因子不能有指数，再加上常数因子的符号和数字间不能有空白字符这一处忘记考虑，导致两个WF没有检查出来。

---

 

三. 分析发现他人bug的策略

• 我是通过手动构造测试样例的方式来进行测试的，主要数据来源是自己写程序过程中测出bug的数据和根据指导书所构想的极端数据，第一是因为针对性比较强，数据力度大；第二是因为我目前还不会自动生成测试样例，只能靠手工做。有些易错点应该是一定程度上的共性问题，因此这样测试也确实能够找出他人的bug。
• 除此而外，我会观察他人代码的解析输入部分，对比正则表达式，由于互测不能用WF数据，所以主要分析是否有判断过当之处；对比解析字符串，主要分析是否有解析不当缺漏可能性从而导致出错的情况。

---

 

四. 应用对象创建模式

• 我在三次作业中都没有使用工厂模式，而是解析字符串再分别创建相应的对象。
• 分析自己的代码，我认为第三次作业中可以使用对象创建模式。通过添加抽象类，将分离出来的输入字符串传给工厂对象，让其内部创立函数对象，即实现简单工厂模式。

---

 

五. 对比和心得体会

• 总体来看，我的代码具有着逻辑复杂、耦合度高等主要问题，也没有完全摆脱面向过程的设计理念，在oo这门课中这些都是需要克服的困难。对比优秀的代码，发现了在思维、设类等方面都有许多值得我学习的地方，希望自己能多加思考，改进思维方式，从而逐步改正我的问题。
• 通过这一单元的学习，我也算是彻底踏入了oo的大门，亲身经历了要如何面向对象设计程序。正如相传的那样，这门课着实非常难，但我们也会从中收获到新的思维、知识等等，相信这些对未来进一步的学习都是十分重要的。
• 在接下来的几个单元中，我们所遇见的只会越来越难。可以说，我们不只要在每一单元的几次作业中将代码迭代扩展，更要在每一个单元之间将我们所掌握的知识体系迭代加深。
  
• 在做作业的过程中看了讨论区大佬们的分享，得到了很多启发和帮助，在此也对热爱分享的同学们表示感谢！