欢迎访问本文原网站：http://www.brandonmoo.xyz/2020/03/20/%e5%a4%9a%e9%a1%b9%e5%bc%8f%e6%b1%82%e5%af%bc-oo-unit-1/
## 1. 程序架构
***
### 1.1 作业一“简单多项式”
---
在这一周的作业中，我还没有面向对象的意识，或者说还没有明确代码会在那一个方向拓展。于是延续了基于面向过程的思想，导致代码十分杂揉，这也导致了第二周的重构，废话不多说，看看uml：
可以看出，对于多项式在input中处理输入，根据正则表达式捕获的group来判定符号，系数，指数等。在Derivate类中求导，在hashmap中用指数作为Key来取系数，然后求导返回。在Main类中优化输出。
---
### 1.2 作业二“支持简单三角函数”
---
重构了代码之后，我将程序大致分为Term, Power, Triangle三个主要类，至于为什么没有常量类，我觉得可以直接用一个BigInteger对象来代表常量。
所以Term 中放置了常量作为系数；Power 幂函数；一个sin型的Triangle和一个cos型的Triangle。由于在设计时考虑到Triangle其实可以看作是一种Power，所以它继承于Power，两个类共有的数据value表示底数（含变量）；index表示指数；coef表示系数。
在Term这个层次，我使用组合，即一个项有系数（常量）, Power, Triangle(sin and cos)四个部分组成。使用组合后，在Term的求导中就逐个使用成员的求导方法，并把为求导的项与求导结果相乘，这样便利所有成员因子后，得到一个Arraylist
具体uml如下：
---
### 1.3 作业三“支持嵌套”
---
这一次作业，由于难度主要在表达式因子以及相应的三角函数方面，我改变了Term类的组成，加入了Arraylist
既然增加了这两个变量，相应的就得改动deriVate, printTerm 和增加一些 add 方法。这也是我代码复杂化的一个问题所在。回过来想，我应该增加一个表达式因子类而不是在term中直接加list。
下面是uml以及一些复杂度分析：
可以看到，由于结构上的高耦合低类聚，导致某些类的方法复杂度太高：结构化不足，和其他模块依赖太强，判断条件多。的确在互测期间，这种短板就显露出来了。
---
## 2. BUG & DEBUG
---
| 作业序号 | bug类型 | 原因 |
| --- | --- | --- |
| 1 | RUNTIME ERROR | long类型超出范围 |
| 1 | WA | 正则字符串匹配错误 |
| 2 | RUNTIME ERROR | Arraylist null判断 |
| 3 | WA | 重复初始化造成表达式因子flash掉 |
| 3 | WA | 括号嵌套失败 |
至于如何发现互测屋bug，我采用了自动生成的策略，发现其实思考一些边际条件似乎更加有效。
---
## 3. 面向对象式重构
---
我在这次作业的过程中，使用了继承类，Power 类可以作为 Triangle 的父类，因为二者求导都是指数乘以系数，指数减一，在对 value 求导，所以 Triangle 的 deriVate() 可以调用父类的 deriVate() 然后再进行下一步求导。同理，构造方法也可以调用父类。
---
## 4. 心得和体会
---
通过这次作业，我懂得了~~千万不要到ddl才肝~~
1. 对于作业要勤于思考，乐于重构，并且积极和讨论区dalao交流
2. 代码方面，写的时候要特别注意（）的遗漏，并且注意一个对象在使用之前必须保证初始化
3. 架构方面，尽量不要使用继承，继承只是一种对数据层面的抽象，接口才是对行为层面的抽象
---