第一单元总结
OO第一单元总结
写在前面：作者苟活过了第一单元的内容。由于假期的贪玩，没有对pre多加练习等等原因导致刚开学对java还不熟悉，更不用说是否能够做到纯粹的面向对象编程。虽然三次作业都成功过中测，但是依然对面向对象的把握不住，依然没有掌握面向对象的核心方法。虽然第二次作业重构了（第一次的屎山）采用了递归下降的方式处理字符串，但是本质上还是采用了一个面向过程的方式在描述代码。（所以这次博客可能能拿我当个错误典型？）
第一次作业：
菜狗第一次写大量的java代码，拿到题目苦思冥想了半天，终于想出来课程组（反对的）反人性的正则表达式，因为一个表达式的包含的内容过于复杂，同时由于有括号的影响，很难构造出一个完美的正则表达式适配于所有的情况，所以用正则表达式直接对字符串进行整体处理异常艰难，同时bug百出，所以第一次作业我被分到了c组。
ok下面是我对自己本次代码的分析：（有点难以入眼了属实）
UML类图：分析的时候才发现写的代码烂的离谱，类和类之间一点关联都没。
1.将加减法和乘法作为两个类，通过正则表达式进行识别，识别到什么形式就生成什么样的对象。
2.主类是Test1，实现了对表达式的搜寻，通过正则表达式对表达式的各项分类。
3.Try1类用于处理指数形式
4.Try3是对最终括号的拆解
类的度量分析：
如图可见虽然基本复杂度不算很高，但是模块设计以及模块结构的复杂程度部分很高，耦合度均较高，增加了维护的难度，同时bug难找也与结构的复杂程度有关。
BUG:
1.强测由三个点没过，主要是因为我采取的方式并没有考虑最后的字符串末尾，于是会出现-0 -> -0-假如后面在跟一个负数就会变成正数。
2.字符串处理的时候直接替换了“++”“--”等两个连续的符号，但是在拆解括号的时候同样会出现“++-”等形式的前缀，导致我的正则表达式识别不了造成reg。
总结：
1.一定不要采取反人性的正则表达式，会造成很多奇怪的bug。要采用正则表达式处理也要采用层次化的形式，同时要添加字符串处理的方法（递归下降等方式）。
第二次作业：
第二次作业相对于第一次作业最大的优化就是采用了递归下降的处理方式，刨去了大量的（反人类的）正则表达式。使得结构层次变得清晰。笔者为了省事并没有建立三个类，直接合并在一起作为Operate，造成了代码过于长，导致代码风格分很低。
Poly() :表达式类，根据[+-]分隔
Term() :项类，根据[*]分隔
Factor() :因子类
if(Cut.getout == '(') {
调用Poly类
}
同时第二次作业相对于第一次增加了自定义函数以及sum方法，对于sum方法我直接采用了字符串替换的方式，f(x)则分析出对应的因子在进行因子的带入。而第二次作业复杂之处在于加入了sin(x)的处理，使得原来的存储结构不能做到很好的存储。于是我对其进行1.sin(x) cos(x) 2.Store:包含sin(x) cos(x) 以及系数 3.最终用 HashMap<BigInteger,ArrayList<Store>>来进行存储。（其实这么看来建立一个标准树对表达式进行存储是一个不错的选择）虽然第二次作业写的还是很烂，但是架构可能是我三次作业里最好的一次了。
类图：
度量分析：
类的度量分析：
可以看出有些很不OO的代码，代码耦合度高，非结构化的成分高，并且单个模块的复杂程度也很高。经过以后的联系希望能够更好的运用面向对象编程的思想，使用抽象类，接口等规范代码。
BUG分析：
互测砍了我28次也没找到bug，但是其实我因为sum函数在第三次作业里被hack了11次。
1.sum中的大数问题，我的start以及end用int存储，不符合题目要求。
2.没处理start>end的问题
3.自定义函数的替换中为了方便对因子我全部进行了加括号处理，但是忽略了不能处理sin(())的问题导致出现reg。
4.（不管怎么说从c房进到b房了）
)的嵌套括号处理以及sin(sin(cos((Poly)))）对于f(x)的处理我采用
while(Poly.contains("fhg其中之一")) {
提取出f(a,b,c)
分析出a,b,c
代入f
同时update Poly
}
而对于sin(Poly)的处理只是在原来的基础上return回了Poly进行表达式处理
遇到 sin(Poly)
cut.pass();//pass sin(
return "sin("+Poly()+")";//此时需要判断返回的Poly()类型，如果不是因子的形式需要加两个括号
cut.pass();//pass )
所以其实对于第三次作业改动的地方并不大，我的不足之处在于为了偷懒直接重写了第二次作业的框架，写了一大个hashmap在顶层，还是没解决pro2的类的创建问题，所以代码看起来依然不美观。
度量分析：
类的度量分析
虽然我前两次做的结构化设计很烂，但是第三次绝对是最烂。以后绝对不能偷懒了，用顶层直接写了一大个Hashmap导致底层的处理异常复杂。同时结构的复杂化以及模块的复杂程度高，debug困难，以后绝对不能为了省事抛弃层次化的设计。
BUG分析:
（终于进A房了，C-B-A)官方样例没出问题，但是被hack惨了，就是上文提到的sum大数问题。
HACK思路：
1.找一些比较容易忽略的边界问题，比如sin(0)，第一次作业中系数（爆int）
2.分析别人的架构，尤其是化简的部分，比如有的将（+1替换成+，但是忽略了+11这种情况）。
3.分析正则表达式，（用大正则的bug实在太多了。。）
总结：
本次作业相对于第二次作业来说改动量并不算大，所以代码成型也很快，做到了不错的正确率。
同时因为偷懒导致出现了很不OO的代码，层次化设计做的很差劲。
