2019 - OO第一单元作业总结

基于度量的程序结构分析

这里用IDEA自带的UML功能和MetricsReloader插件进行分析。

方法的复杂度分析主要基于循环复杂度的计算。循环复杂度是一种表示程序复杂度的软件度量，由程序流程图中的“基础路径”数量得来。

1. ev(G)：即Essentail Complexity，用来表示一个方法的结构化程度，范围在[1,v(G)]之间，值越大则程序的结构越“病态”，其计算过程和图的“缩点”有关。

2. iv(G)：即Design Complexity，用来表示一个方法和他所调用的其他方法的紧密程度，范围也在[1,v(G)]之间，值越大联系越紧密。

3. v(G)：即循环复杂度，可以理解为穷尽程序流程每一条路径所需要的试验次数。

• 第一次作业

这里可以发现，iv(G)和v(G)的值在某些方法中比较大。主要是由于在第一次作业时对象化思想还不够，代码仍然是“面向过程”的思想，把不同的方法当作是函数进行调用。并不能体现对象间信息传递的特点。

• 第二次作业

这里的Polynomial.merge()方法的ev(G)值过大，说明它的结构很“糟糕”。经过查验发现是因为使用了ArrayList来保存每项，而在merge（合并同类项）的过程中，我使用了四次for循环，这显然并不是一个好的方法。可以考虑在以后类似的情况下使用HashMap。

• 第三次作业

Expression的构造方法额ev(G)值、iv(G)、v(G)值较大，这里可能的原因是我在解决括号嵌套问题时使用了栈的方法，把所有当前第一级的“（”和“）”都替换成了“{”和“}”，这个过程如果能够另设一个方法的话可能会使代码层次更好。还有关于嵌套求导的部分我把他都放在了TriFunc类中，这样会使最后的结构很冗余，应该再另外设置一个类。

自己程序的bug分析

• 在第一次作业里，我的bug主要是以WRONG FORMAT为主，比如不可见空格、其他特殊字符等。在运用正则表达式时，由于不熟悉而造成了许多错误。这些bug都是很明显的，也很容易做出修正。
• 在第二次作业里，我的bug不多，并进行了简单层次的优化，将每一项作为一个三元组进行简单的合并同类项。
• 第三次作业的难度明显有了较大程度的提升，在进行自测提交时出了很多的Bug，主要是在正则表达式的运用上。比如在进行括号的匹配时，.+和.+?就有很大的不同。由于时间和难度的原因本次作业我没有进行优化。
• 总的来说我这三次作业在实现正确性上没有较大的问题，主要还是在于性能的优化部分，以及整体的设计模式和风格上还有很大的提升空间。

互测bug分析

要读完一个互测屋7个人的代码并在理解的基础上编出合适的测试样例显然是很有难度且不现实的，因此我在前两次的互测环节主要还是针对WRONG FORMAT。而第三次作业由于没有互测制度的改变，我没有能够成功hack。这也是我今后需要学习的地方，争取能通过一个自动化的工具更加高效地完成互测部分的内容。

Applying Creational Pattern

这三次作业虽然完成地并不算好，但是我能够感觉到自己面向对象的思想正在一步步地成熟。

首先是第一次作业，还是延续了此前的“面向过程”思想，虽然实现了功能，但是不符合本课程的初衷；第二次作业，“面向对象”思想初具雏形，建立了单项式、多项式、主类三个类；第三次作业，参考了课程建议建立了多种类，并设置了统一的接口“求导”来使整个project的联系更加紧密。由于能力的欠缺，我对后两次作业都没有能够在上一次作业的基础上添加功能完成，而是都进行了重构。这在效率上是一个很大的损失。希望在以后的作业中我能够逐渐实现提高编程能力、成熟设计思想的要求。

 

转载于:https://www.cnblogs.com/lsw-CS-2019/p/10585189.html