说来惭愧，在很久之前修这门课程的时候总是不能理解面向对象辩证思想的精髓所在，又没有用软件开发的标准严格要求自己，所以导致写了一些类C程序后草草收场。时隔多年，课程的风格变化与老师和平台提供的帮助，加上今年对于Java语言上更熟练的使用，让我在第一个单元的学习中得到了很多，虽然并不能像大神一样总结出技术上的种种共性要点，但仍然可以在说自己作业的具体问题之前，总结出几点基础的东西，也算是给和当时的我一样基础不好的同学一点帮助。
Part 1. 再次学习这门课总结的小TIPS
1. 面向对象设计形象化的理解
在各大搜索引擎如果你去搜索面向对象程序的特征和区别是什么，你只会得到三个关键词：封装、继承、多态。说的一点错没有，但是其实对初学者思想的转变用处不大，无法让你通过理解这三个词就能一下子写出典型的面向对象程序。如果你之前写了一两次类C程序，在思想的扭转上苦苦不能完成转变，我相信造飞机的例子就是一个非常典型的讲解，会有所帮助。汽车是流水线的产物，强调整体性，装配的连贯性；飞机则是组件外包，组件各自生产，统一完成组装的产品，毕竟这个世界上没有对应飞机那么大的流水线。
我们在编写C语言程序的时候，养成的是一种问题分解的思维步骤：这是一道怎样的数学问题，输入是啥，输出是啥；弄明白要求后我们会按照输入处理→数据计算储存→数据输出的线性方式对问题的解决进行构想。但写面向对象的程序更像是画设计图，虽然我们仍然无法避免输入，输出，但你首要思考的是我们要用几种类来处理这些问题，各种类之间如何设计方法，如何创建实例并调用。就好比我们处理了三次的字符串求导，对象有表达式，项，因子这三种，调用是层层递进的关系，而我们只需要对处理不同的对象创建相应的方法，将类内部变量隐藏好，将该传递的参数设计好，问题就已经完成了分析，迎刃而解了。
万事开头难，你的思想如果从画流程图改成画平面设计图，那么对于面向对象设计的初步转变其实就完成了。
2. 标准与规范
之所以把这一点放在第二点，是因为课程引入的代码风格检测同样是评价作业完成情况的标准，而且与我们其实是我们写代码时按顺序来讲关注的头几个问题之一，之前老师上课时调侃：“一些同学的风格分是一次一次从0变成100的”，这算是一个非常严肃的问题。我们的作业代码其实是不要求注释行数的，所以并不需要“照顾”互评同学的可读性（这只是一个不负责任的说法），你甚至可以不照顾自己的可读性，但这并不意味着风格不重要。
课程提供的加上Idea上整合的一些checkstyle工具可以从最基础的层面实时帮助我们改掉写代码的一些坏毛病、坏布局等等，在写的初期就坚持这么做可以有效地为以后做工作避免麻烦（亲身经历）。课上举例那个 int i = 0; int ii = 0;int iii = 0;，就是我一个学竞赛的舍友出门工作第一个月写的代码风格，被BOSS疯狂要求返工……按理来说算法上我这位舍友应该远超校招其他新人，但是代码也是讲究脸面的，不会有任何一个开发组领导会允许这种情况出现。
回到我们的课程初衷，除了面向对象的设计思想培养训练，其实软件开发素养的培养也是最初的目的之一，写的时候按标准要求自己，不光意味着更高的风格分，还意味着你能更好的读懂你写的东西。行长度，布尔表达式复杂程度，方法长度，文件长度等等都会时时提醒你代码设计上的不足，好的代码不会超长，更不会在命名上出些乱七八糟的东西，所以如果能够在写的时候规避这些问题，可以从另一角度督促我们注意设计的细枝末节。
3.设计的重要性
这个应该已经适应这门课程的同学都有所体会，设计的时间本身并不是无效的、占用写代码时间的。在我看来，我们做一次作业用的总时间等于设计思考时间加上码代码时间，反而是一个定值。设计的时间越长，想的越清楚，码代码的时间耗费的其实越短（当然不要举一些极端的例子来反驳这句话）；看指导书的时间越长，DEBUG的时间就越短。我这几次强测都有一点小错，其中有两个就是因为没看到系数的范围，导致自己先入为主定义了一个LONG型，被同一测试组的同学疯狂hack -_-||（毕竟是摆在明面上的错）。
如果你在一周的作业上周二晚之前用的总时长是24小时，那我觉得，这里面可以用2小时去通读指导书，6小时设计，包括自己要用到的类，类中的方法，输入处理，输出处理，数据储存处理等等，看的越全面越好，想的越细节越好，这样编码的过程中会省出很多南辕北辙的思考成本，DEBUG的时候也会遇上更少的BUG。
Part 2. 从自己作业中总结的一些问题
1. 输入处理
这其实就是我说的思考的重要性的体现，我看一些同学其实已经用文法的格式总结了这次作业的输入格式，应该说是比较清楚，但是在互评中也确实有没想清楚的同学存在。正确的我就不写在下面了，第三次作业讨论区有一些同学分享的清楚的定义。这里说一下我听到的某种问题。
比如：嵌套因子sin cos括号内是因子而不是表达式，所以如果括号内是一个表达式，那一定要是表达式因子，所以可以出现 sin((x+1))，不能出现sin(x+1)。这个是我听说过的一个比较典型的理解错误，指导书没读懂，不过出这个错的基本都自己DEBUG改过来了，否则中测都过不去（大概）。
2. 输出处理
这个是我自己在第二次作业中出现的问题，还因此扣了代码格式分，顶层没设计好搞了好多布尔表达式，然后写了个200行方法……
比如： 多因子输出时处理开头系数为1，-1的情况就是用很多的布尔表达式去判断如何化简，而且还出错了……，出现了形如“*sin(x)”的错误（系数为1，化简扑街），我后来想了想，在存数据的时候系数不应该和后面的各项因子割裂开，然后输出的时候挨个去判断，才有了这种容易出错的问题。
3. 存系数用的long
感觉估计一个班并没多少犯这个错的，略。
4. 正则表达式的构建
这个严格来讲不算个BUG，只是像之前研讨课所说的，避免大正则出现（我前两次写的也是大正则），大正则一时爽，互评直奔火葬场。而且大正则写对了还好说，写错了可就坑了DEBUG的自己了，所以，除了第三次作业，前两次最好分层写，这也是我从互评中学到的一些简洁的典范，第三次涉及到递归，也没法写大正则，算是强制治了一下疑难杂症……