OO第一单元总结分析
作业分析
第一次作业
设计
质量分析
总结
- 第一次作业明显的表现出面向过程编程的思想,没有层次划分,只是简单的根据功能划分了多项式与处理输入两个功能.
- 第一次作业我的第一版由于使用了长正则导致爆栈, 当时对正则表达式的独占模式了解不多,所以选择了重新设计,采用逐项检查的形式,由于时间的紧张导致代码质量不高
bug分析
- 产生原因 : 在简化 +1x, -1x 之类的输出时考虑不全导致
- 修复过程 : 增加为考虑情况的分支即可
第二次作业
设计
由于个人对第一次作业匆忙的,面向过程的,糟糕的设计十分不满,所以第二次作业在思考之后,放弃了处理比较方便的三元HashMap形式,试图进行层次性设计,虽然在本次作业中较三元组方法比较繁琐,但是很好的锻炼了我的思维,给第三次作业的设计积累了经验
质量分析
总结
- 之前一直没有接触过面向对象思想, 第二次作业可以说是一次设计尝试, 试图使用了继承,接口,泛型等特性来统一化操作
- 在这次设计的过程中, 自己渐渐有了一些面向思想的感悟 :
- 每一个层次只关心该层次的事情,其完成行为依赖于比自己底层的类,即只需要使用底层向上暴露的统一接口,而不用关心其具体实现
- 继承,接口等一大好处就是使得底层向上的接口统一,上层只需发出命令,具体完成行为由底层的具体类型来决定
- 面向对象的关键在于消息的传递, 对象可以向什么对象发出什么消息,对象可以从什么对象接受什么消息
bug分析
第二次作业的强测和互测中均未被发现bug
第三次作业
设计
第三次作业的设计在第二次作业的扩展上完成 :
-
对输入进行简单的预处理
-
核心递归下降模块
- 一个表达式由一个项列表组成
- 一个项由一个因子列表组成
- 因子从统一的父类继承,因子中特殊的有三类:
- sin/cos : 因子内部属性有一个任何类型的因子
- 表达式因子 : 因子内部有一个表达式
质量分析
总结
- 第三次作业的核心在于对嵌套的处理,对此我使用在建立表达式时递归处理,当在建立表达式/项/(sin/cos/表达式因子)时,当使用栈检索到最外层的括号时,传入括号中的内容建立一个新的因子并存储到自身的属性中,递归终止条件为该建立依赖的字符串不再有括号,则正常建立即可
- 递归下降的做法比较简单,模式化,但是处理起来效率低,对作业要求的60个字符之内还可以正常运行,但是处理较多嵌套速度很慢,树结构的效率应该比递归下降的效率要高
bug分析
- 产生原因 ; 第三次作业的bug给了我一个很大的教训,这个bug的表现形式是对于过多的嵌套运行会超时,所以我主观的认为是由于递归建立和递归求导的过程中耗费大量时间导致的,所以在这两个模块做了大量的优化,但是效果一直十分不明显,之后在同学的帮助下发现大量的时间是耗费在输出过程上的,在仔细阅读代码之后发现我在输出过程中每次判断是否为空串都调用了对应了的toString()方法,在一个输出方法中调用toSting()多达4,5次,而某些toString()是嵌套调用底层的toString()的,所以会耗费大量的时间
- 修复过程 : 在每个输出方法最开始调用一次toString()并将返回结果保存
反思
- 经过三次作业之后自我感觉在这个过程中还是比较吃力的,不论是在设计过程中还是实现过程中都存在很大的提升空间
- 在设计中 : 对面向对象思想有一点认识,但是很表面,离一切都是对象还有很长距离
- 在实现中 : 对Java语言的特性还是不够精通,存在大量的一知半解现象
- 要积极学习大佬们的先进经验,例如语法分析器praser,工厂方法等概念自己一无所知,要主动去分析优秀的设计样例,思考其设计目的,向合理的面向对象设计靠拢
写在最后
你可以菜,但要比昨天强
