301
社区成员
发帖
与我相关
我的任务
分享OO Unit 总结
OO_Unit_Blog
个人体会
作为一个没有参加过oopre的java小白来说，这三次作业做得让人十分的煎熬，因为抛开架构设计不谈，语言也得是一边学一边用，好在助教团队在每次的实验上机代码中有一些提示，OO加油站里也有不少的“小灶”，也算是磕磕绊绊的完成了三次任务（悲）。
作业概述
UML类图：
代码复杂度分析：
方法复杂度：
hw1:
- __作业要求__：hw1主要任务是脱去括号，但真正的难点在于架构的设计，（_所以这也是我真正最头痛的一周，因为要从一个连java语言都不太懂的人一步走到自己架构整个项目代码，好在学长教了我很多_）。
- 基本思路:
（_此为1、2次作业目录_）
- 预处理：就是简单的对表达式进行字符串替换，包括多符号的处理，空白项的处理，让整个表达式看上去更加的规整一些，因为后来处理表达式的时候又会出现"++"的情况，所以我干脆对预处理写了一个方法deal,最后在输出答案的时候又调用了deal。
- 表达式解析: 采用trainning中给出的递归下降的方式，使用Lexer和Parser的方式来递归解析经过预处理的表达式，构建Expression\Term\Num\Variable类，定义接口Factor,让每个单位实现这个接口，在Expressio和Term中设置Arraylist Terms 和 Factors属性来保存解析好的下层单位。这样在toString的时候也可以类似于Parser一样的去递归toString,也好安排一点。
- __表达式计算:__：在完成第一次作业时，学长告诉我后面肯定涉及到求导的作业，所以事实上我在分析的时候，我的最小单元(或者说Parser的出口)是只有x和Num的。然后主要的难点在于表达式因子和表达式因子的乘法，为了避免深浅克隆的问题，我在做这类计算的时候都是根据多项式相乘的结果，先new一个新的对象，然后直接旧的clear,新的addAll。(因为一开始就有人提醒我，反倒没遇到研讨课上好多同学说的这种问题，作为一个小白其实挺想看看到底会导致什么样奇形怪状的bug的)。
- __表达式输出:__：这个没什么好说的，就是重写每个实现了Factor接口的toString方法，Term之间用+，factors用*，唯一的就是我的factors里可能是有+(表达式因子相乘)，这一点在toString需要特判一下就好。
- __性能优化:__：因为为了应对后面作业的求导，所以前文提到我的Parser最后factor单位是x,所以需要化简一下，写了一个方法Simplify,认为单元是系数x^次数(第二次作业变成系数x^次数*exp(指数)),利用字符串处理的手段进行了简化。
- __Bug分析:__：第一次作业没能通过强测进入互测，主要原因是在提交了正确的答案以后想简单的通过字符串替换的方式让整个表达式变得更简单，结果出现了意想不到的Bug(有点过于低智这里就不再多说了。)
- 互测: 没进去不多说了（悲伤）。
hw2:
- 作业要求:hw2在hw1的基础上提出了新增一个Exp因子和自定义函数调用，其中自定义限定为只有三种f,h,g，Exp因子要求加上必要的括号(事实上就是要求表达式因子再加一层括号)
- 基本思路:因为有了第一次作业的经验，对Java语言稍微熟悉了一点，所以这次作业事实上并没有让我感到太大的困扰，我选择把自定义函数也看成一个新的因子，当我们遇到f(,g(,h(的时候就将其作为一个新的因子分析就好，而Exp因子也是同样的处理方式，遇到exp(也采用同样的方式。
- __自定义因子的实现__：
构建自定义函数类，该类接受一String，拥有属性expr和parameters用来储存参数个数，顺序，以及函数表达式。主要包括两个方法，一个DeFFunction方法用来解析给出的自定义函数，另一个ReplaceFun用来调用解析好的函数，接受参数，返回带入参数得到的表达式。因为作业指导里提到最多只会出现三个自定义函数，所以直接创建三个对象，类里写好方法对自定义函数的表达式和名字进行解析，注意参数的顺序，这样在传参数的时候才能知道配对的方式。唯一的难点在于实参替换形参的时候，因为事实上我们也是在调用Parser在进行分析，所以不能让形参x走到原来的Variable里去,所以在实现分析函数表达式的时候把里面的xyz全部替换成其他（后来反应过来事实上yz可以不替换，因为我们的自变量本来也没写yz的)
- __Exp因子的实现__：这个解析比较简单，就是搞一个Exp因子类，实现Factor的接口，至于提到的括号问题我的解决方案是在toString的时候全加上两层括号，这样虽然会产生“不必要的括号”，但绝不会丢掉“必要的括号”。
- 性能优化:这里事实上不需要太大的改动，就像前文提到的，对单位元形式做一个转换，把exp加进去考虑就好。还有就是exp括号的问题，虽然我的正确性得到了保证，但是绝对导致了我的性能分不会太高，但却是没想出特别好的方法。
- Bug分析： 主要是算法的问题，我把Factor^Num次幂全部调用了表达式因子相乘的方法，导致即使前面的Factor是一个单项式也会进行复杂的方法调用导致了超时。
- 互测: 主要是一些自己犯过的错误和自己构造的特别的数据拿去hack别人，还有一部分来自大佬写的评测机（真是一把hack别人的利器）。
hw3
- __作业要求__：本周作业相对简单，要求在前两周的基础上加上求导因子，还加上了函数嵌套调用。
- 基本思路: 新建求导类，遇到dx(，调用表达式解析把表达式因子传给求导因子类，调用类方法递归求导，返回求导结果。
- Bug分析:终于在鏖战了一个下午之后，我放弃了部分自己的所有强测Bug，明明觉得自己第三次作业应该一下就写好了，结果出来了一堆莫名其妙的bug,可能也有我第二次作业的Bug？总之它已经成为一坨了。得分的性价比已经太低了。
心得体会
OO是一门好课。
通过完成这样高强度的作业，确实让我收获颇丰，起码感觉到了面向对象设计与构造应该是一个什么样的过程，它跟面向过程编程的区别在哪里
这三周的的OO作业绝对是让我痛苦的，但可见进步也是神速的，虽然没办法像其他同学一样高质量的写出无懈可击的代码，但我从一个连语言都不知道的小白也是突击成为了起码能通过中测的菜鸟，不能说毫无收获，只能说进步空间还很大，就是不知道分数占比是怎么样的导致人心里很慌，真的不想进收容站啊~(等下再去改改第三次的Bug) :(
未来方向
首先这门课的含金量是真的很高，但付出的时间也是真的多，我希望课程组或许可以把分数的占比公布一下？不然不知道分数的性价比到底高不高，学有余力能力强的同学可以多卷一些多拿些分，时间紧张的同学也可以权衡利弊选择重要的部分完成，因材施教，增强自主选择的权力，比如我今天改了一天的Bug结果总分只多拿了0.5分的话，那真的是很让人难过了。
...全文
请发表友善的回复…
发表回复
