面向对象第一单元总结

1.第一次作业

1.1实现思路

第一次作业的题目是实现一个简单的对一元多项式进行求导的功能。实现这个功能首先是对输入进行识别,识别合法输入和非法输入,合法输入进行下一步,非法输入返回“WRONG FORMAT! ”,识别完后消去多余的空格和运算符,然后用arraylist将每个项保存下来,之后进行求导,最后再进行合并同类项和输出。考虑性能分,合并同类项的时候要尽量找一个系数为正的项放到队首。

1.2代码结构

程序入口在homework1这个类,这个类除了处理ctrl+c这种输入进行检测外,逐步调用StringProcess类和ArrayProcess类进行检查处理和输出;在是StringProcess这个类里面实现项的结构,封装系数和指数,为了适应大数运算,使用BigInteger类保存,同时对输入进行检查,去掉空格和多余的运算符,以及建立arraylist的方法也封装在这个类里面;最后在ArrayProcess这个类里面封装了合并同类项的方法和输出的方法。

1.3程序结构分析

第一次作业的度量情况如下

总长度233行

方法个数、控制语句数量等信息如图

由于这次的任务比较简单所以各方法平均行数不多,主要集中在少量的方法里面,主要是一些匹配的字符串和匹配操作占行数比较多,可能可以再拆分,将一些字符串类里面的静态变量

1.4 bug相关

由于这次的任务比较简单,数据的复杂度不高,我本地建立了一个小样例库进行测试,主要检测ctrl+c和其他的空白符以及使用贪婪模式导致爆栈问题

2.第二次作业

2.1实现思路

这次主体跟第一次作业非常相似,只是增加了项的类型和之间相乘的关系。所以数据类型使用了保存系数,x指数,sin(x)的指数、cos(x)的指数的四元组。使用hashmap的方式储存项会比较好化简,但我还是使用了arraylist的方式保存项。

2.2程序结构

主体结构跟第一次作业很像,依旧是homework函数作为入口,Xiang类作为数据结构,依次调用Poly、DuoXiangShi、Shuchu这几个方法类进行检查、处理、建立项、合并同类项、输出。这次的数据结构实际没有设计好,应该将项的求导功能封装在Xiang这个类里面,不应该使用DuoXiangShi这个类进行具体的求导操作。而合并同类项中我也只是进行了各项指数相同的项的合并和cos(x)^2+sin(x)^2的合并,输出的时候不输出指数为0的项,当一个项的所有指数都为0且系数为1时才输出1,不输出系数为0的项,同样将系数为正的项提到第一个。

 2.3结构分析

第二次作业的度量情况如下

总长度478行,平均16.48行,依旧跟第一作业一样,字符串和匹配代码可以拿到方法外进行复用。

2.4 bug

这次由于数据复杂度和时间安排的关系,我没有建立完整本地的输入库,我只有在编程的时候建立了一个小规模的库,之后debug阶段和互测阶段使用和同学合建的测评机进行了几万次的随机数据测试。可以快速简单地找出bug,不过大部分是同类型的bug。bug主要集中在合法输入的判别上,求导的时候负号的问题,指数为0的情况,实际上主要是一些边界条件的问题,应该在写代码之前建立输入库,依照库写代码,当然犹如人的精力有限,使用测评机进行分析。

3.第三次作业

3.1实现思路

这次的由于嵌套关系的存在,在数据结构方面分成term类型和factor类型,在检测输入的合法性的时候会根据term类和factor类进行递归的检测,为了代码复用的方便,我在对括号内的字符串进行递归减测合法性之后,将括号内替换成(x)或x^2使用第二次作业的正则字符串进行合法性判断,还要额外检测右括号后面跟着数字的非法情况,防止替换后非法输入变成合法输入。检测完之后建立数据树,数据结构是一层term一层factor的结构,将term内的用+号或*号连接的部分分割开,逐个建立factor,组合到一起。

3.2程序结构

 

由于这次的作业比较复杂,所以程序结构也比较复杂,但实际结构差不了很多,也是识别->处理->输出,由于时间分配的原因没有写合并函数,函数求导的时候就是输出字符串,知识在求导的过程中进行了一些不输出0次方、一次方不输出系数这样的操作。不过这次将求导方法和输出方法封装在各自的类中,而且求导的时候可以很方便的自上而下逐级调用各自的求导函数和输出函数。以及由于会在多个地方输出非法的输入的信息,所以直接将输出"WRONG FORMAT! "和推出程序封装成了一个类。

3.3结构分析

如图所示

这次的中代码行数572行,由于有很多方法,所以方法平均行数9.86行,各方法最大行数也不是很多,程序结构还是比较成功的,当然对出入进行处理检测括号外的+号、*号、最外层的两个括号之类的还是可以独立成一个类进行复用的。

3.4bug相关

 这次的bug比较杂,但主要集中在正则方面,主要是递归方面的问题,理清楚判断逻辑就很好解决,主要是括号内因子的识别调用到表达式的识别的问题。由于求导是各自factor和term进行管理的,所以求导只有一个cos求导没有带负数的bug,由于没有化简所以没有在化简方面出现bug

由于没有建立输入库,bug主要是靠自建测评机检测的,而且这次测评的要求限制的比较严,边界数据不是很多,主要用测评机跑跑就行,互测由于限制输入必须正确,所以主要检测出一位同学输入的判断有问题,主要是他对因子的检测的不对,调用到表达式的检测,还有一位同学的求导出现问题,导致结果不对。

Applying Creational Pattern

前两次作业数据结构比较简单,都是采用工厂模式,识别各项和各项的系数指数之类的参数传递进去。

第三次作业由于factor和term类的子类都会有一些公用的数据结构,所以使用动态原型模式和构造函数模式,用子类的构造对共同的数据结构进行赋值同时初始化各自的标志符。

原文地址:https://www.cnblogs.com/hunry6th/p/10596874.html