BUAA-OO-U1总结

秦子奇22371144 学生 2024-03-21 21:52:32

BUAA-OO-U1总结

1.三次作业架构分析

hw1:

hw1作业难度相对简单，只涉及关于简单表达式的解析，另外还要注意指数的处理。在本次作业中我基本沿用了Train中给出的代码的架构，用lexer类专门负责字符串的读取工作，用parse类负责专门的解析工作。在表达式计算方面，我采用的是边解析边算，即用ArrayList<Data>来表示每一个Factor的数据特征（Data是最小单元），在下一级解析完退出后立马与上一级的结构的ArrayList<Data>进行相关的运算。(例如在parseTerm中调用parseFactor退出后，parseFactor返回一个Factor,Term中的数据表与Factor中的数据表进行相乘，而在parseExpr中则与parseTerm返回Factor的数据表做相加运算)。所以，为了方便管理有关运算的方法，我将所有有关运算的方法集成到了工具类Calculate中，在需要运算时实例化，即可随意调用其中的方法，进行运算。

hw2：

这次作业对第一次的架构冲击相当大，几乎每个类都做了许多调整。hw2加入了函数和指数以及多层嵌套括号。多层括号在第一次作业中我的架构即可支持，而关于函数的处理，我和许多人所用的字符串替换方法不同，我是直接对函数进行解析运算，将算出来的结果放在了Funtion类的实体中进行储存,并在Function类中实现了计算函数方法，往其中传入相应数量的Factor，经过计算后返回一个Expr。这种实现方法虽然相比字符串替换更慢，但性能更稳定，面对奇奇怪怪的数据点时兼容性更好（翻译：更容易得分，不容易被Hack）。关于Exp函数，为了支持此函数，我对Data做了一些改进，原来的Data表示：a*x^n 变为 a*x^n*exp(Arraylist<Data>)。所以为了适应此改动，也需要对工具类Calculate中进行相应调整。这时第一次作业把计算方法抽象出来的好处就体现出来了，不然一个类一个类改过去，又麻烦又容易出错！还有为了得到性能分，还需对exp进行进一步的处理，这是toString时候的工作，具体细节就不做过多赘述。

hw3:

最简单的一集！在做这次作业之前，我惊喜的发现一些要求在前两次作业就实现了。本次作业只需在原先的工具类Calculate中加入求导运算，以及在lexer中加入对倒数符号的识别，以及在parser类中parseFactor加入对导数因子的相应即可达成目的。虽说在第二次作业中有人提出了一些情况下特殊的优化方法，比如把一个exp拆成两个exp。但在仔细的权衡与考虑下，我觉得做这种优化与我之前的方法差的有点远，如果强行实现有可能给我的代码造成崩溃的危险，导致各种奇妙的bug,所以我决定放弃这一部分的优化分，追求代码的稳定性。

以下是本单元总体架构：

bug分析：

hw1:

在本次作业中强测虽然得了满分，但在互测中被Hack了。原因是在做同类项合并时忘记了多个零的情况，所以在bug修复中对unite方法进行了改进，解决了问题。

hw2:

强测爆了一个点：数据点2。原因就是没想到x的指数能如此之大！所以修改了x指数的数据类型，解决了问题。

hw3：

强测没问题，互测被Hack了，为何？对exp()括号中的表达式同类项合并出了一些小问题，导致了错误。对其处理一下即可。

代码复杂度分析

方法复杂度：

类复杂度：

从以上分析结果来看，我的代码在一些类中的判定结构过于复杂，比如toString方法，原因使我把所有的toString工作都放到了Expr类中，导致工作量过于巨大，应当把一些判断分支拆散到一些小的方法中，或者把toSting的工作下放到Term以及各个Factor类中，有助于减小Expr中toString类的复杂度。以及parser类中的几大方法，在经历过三次迭代后一些方法的结构都已经变得相当复杂，我个人认为的解决方案是把大方法查分到小方法中，以减轻大方法的负担。

其余在复杂度上明显偏高的的就是工具类Calculate中一些关于同类项的判定方法。如果需要优化则需要将判定工作拆分到各个类中，比如在Data类中重写equals方法，来减轻同类项判定方法的复杂度。

心得体会：

在本次作业中，我深刻领悟了代码架构的重要性。好的架构能使后续功能扩展更方便。所以在编写代码时，我们需要做出更加长远的选择，可能目前还勉勉强强的方法到了下次就直接崩溃了。虽然我们要尽量避免这种情况，但如果真的发生了，就应当及时重构，不能舍不得老架构（否则就会面对海量的bug）。本次作业我们学到的核心思想就是递归下降，其背后的支撑则是对接口和继承的理解。由于本次许多类在本质上有相似之处，所以熟练使用接口和继承就能使我们的代码变得清晰灵活，即增加了可读性又提升了正确性。所以在之后的作业中，在一开始我就会着重思考代码架构的可扩展性，以及在迭代的过程中及时重构。