oo第一单元总结：表达式解析开发全记录

沈钡-24373462 2026-04-01 00:39:02

基于度量的程序结构分析

一、基础代码维度度量

本部分统计类的属性个数、方法个数、类总代码规模、核心控制分支数目，完整度量如下：

类名	NOA(属性个数)	NOM(方法个数)	CLOC(类总代码行)	核心控制分支数目
Main	0	1	12	0
Term	4	9	63	2
Polynomial	1	23	331	17
Expr	10	15	282	26
Solver	4	3	105	8

二、经典OO度量与内聚耦合分析

1. 核心OO度量表

类名	WMC(加权方法复杂度)	CBO(类间耦合度)	TCC(类内聚度)	CCC(类完整度)
Main	1	2	-	-
Term	11	2	1.0	1.0
Polynomial	40	4	0.9	0.95
Expr	38	4	0.75	0.8
Solver	12	5	0.8	0.9

2. 类级别深度度量

class	OCavg(平均圈复杂度)	OCmax(最大圈复杂度)	WMC(总加权复杂度)
homework.Main	1.0	1.0	1
homework.Term	1.22	3.0	11
homework.Solver	4.0	7.0	12
homework.Expr	2.53	12.0	38
homework.Polynomial	1.74	6.0	40
Total	-	-	102
Average	2.1	5.8	20.4

3. 方法级别核心度量

method	CogC(认知复杂度)	ev(G)	iv(G)	v(G)
homework.Main.main(String[])	0.0	1.0	1.0	1.0
homework.Term.mul(Term)	0.0	1.0	1.0	1.0
homework.Term.equals(Object)	2.0	1.0	2.0	3.0
homework.Polynomial.addTerm(...)	2.0	1.0	2.0	4.0
homework.Polynomial.pow(BigInteger)	3.0	2.0	2.0	4.0
homework.Polynomial.deriveX()	2.0	1.0	2.0	3.0
homework.Solver.solve()	3.0	2.0	2.0	4.0
homework.Expr.addOrSub()	3.0	2.0	3.0	5.0
homework.Expr.simplify()	4.0	2.0	3.0	5.0
homework.Expr.xuanze()	5.0	3.0	4.0	6.0

4. 内聚与耦合综合分析

内聚性：Term、Polynomial、Solver为功能内聚，类内所有方法均服务于单一核心职责，内聚度优秀；Expr为逻辑内聚，多分支解析逻辑混杂，内聚度中等；Main仅为程序入口，无内聚性要求。
耦合性：整体为低耦合设计，所有类均无内容耦合、公共耦合等不良耦合，仅通过参数/返回值完成数据交互；仅Expr、Solver存在合理的标记耦合，整体耦合度均处于优秀区间。
复杂度风险：Expr、Polynomial的WMC、圈复杂度显著高于平均值，是程序复杂度核心，也是优化优先级最高的模块。

三、UML类图与类设计考虑

1. 标准UML类图

2. 类设计考虑

Main类：设计目标为程序唯一入口，仅保留main方法完成启动调度，职责极简，符合单一职责原则，避免入口逻辑冗余。
Solver类：设计目标为全局流程协调者，负责输入处理、函数定义解析、递推公式展开，隔离输入层与核心解析层，拆分输入逻辑与业务逻辑，降低耦合。
Expr类：设计目标为表达式解析核心，负责将字符串表达式递归解析为Polynomial对象，拆分加减乘除、幂运算、求导、条件分支等子方法，降低单方法复杂度，支持自定义函数与递推函数扩展。
Polynomial类：设计目标为多项式运算核心，封装多项式的加减乘除、求导、表达式生成等核心能力，通过addTerm自动合并同类项，保证多项式规范性，对外暴露统一的运算接口，隐藏内部实现细节。
Term类：设计目标为多项式最小单元封装，将系数、x/y指数、e指数封装为独立对象，提供取反、相乘等原子运算能力，核心不可变属性设为final保证数据安全，为上层多项式运算提供基础支撑。

四、程序设计优缺点点评

1. 优点

核心类严格遵循单一职责原则，高内聚低耦合，职责边界清晰，封装性良好，无职责混杂的设计问题。
架构分层明确，输入调度、表达式解析、多项式运算、数据封装四层职责分离，新增功能无需重构核心架构，扩展性强。
数据类设计规范，Term的不可变属性保证了线程安全与数据一致性，Polynomial对外屏蔽了项的管理细节，接口简洁易用。
支持自定义函数、递推函数、二元求导、条件分支等扩展能力，功能覆盖完整，满足作业需求的同时预留了扩展空间。

2. 缺点

Expr类复杂度超标，多分支递归解析逻辑嵌套深，圈复杂度与认知复杂度显著高于平均值，可维护性差，易出现解析bug。
异常处理缺失，无表达式合法性校验、未定义函数拦截、非法字符处理等鲁棒性设计，输入异常时程序易崩溃。
性能优化不足，Polynomial的同类项合并采用遍历列表实现，无哈希索引优化，大表达式解析时性能损耗大；Expr频繁的字符串截取也存在性能冗余。
依赖倒置不足，Expr、Solver直接依赖HashMap实现类，而非Map接口，替换数据结构时需修改类构造函数，违反面向对象的依赖倒置原则。

架构设计体验及自己程序的bug

第一次作业

架构设计体验

只有 Main Solver Expr Polynomial 四个类由于只有x项就没有用到term类直接在Polynomial中用treemap存储
然后就没什么特别的
在Expr里面根据加减乘法的优先性拆成若干个Expr1.getPolynomial()相加减
再把每个Expr1.getPolynomial()（没有加减法的情况下）拆成若干个Expr2.getPolynomial()（而这个也就是因子）
然后因子即 Expr2.getPolynomial() 无非就是四种情况
于是先判断 Expr^Expr
再判断(Expr)
再判断x还是int

Polynomial 差不多是AI写的

Bug

没有用Biginteger

第二次作业

架构设计体验

1.新增了指数函数因子 exp(Expr)
考虑到存储功能增加了term类拓展一下加减乘法即可同时优化了负号后置（关于系数排序了一下）

2.新增了选择式因子 [(ExprA==ExprB)?ExprC:ExprD]

this.polynomial = ExprA.getPolynomial().sub(ExprB.getPolynomial()).isEmpty() ? 
                   ExprD.getPolynomial() : ExprD.getPolynomial() ;

3.新增了自定义函数 f(x) = 表达式 (name(x) = Exprf)
这里先是在Solve中添加了存储自定义函数<String,Polynomial>的hashmap（显然在hw中没用到）
然后在Expr中多加了两个形参 funcExprMap （自定义函数表）和 polynomialOfX （当前表达式的自变量）

Bug

x的指数没有用Biginteger

第三次作业

架构设计体验

1.表达式从单变量 x 扩展为双变量 x, y
这边有点偷懒了就是在Term里加了一个yexp
其实或许可以在Term里面弄一个<String,Biginteger>的varIntMap

2.新增了求导算子 dx, dy 和 grad
就简单在 Polynomial中加了三个求导函数都是差不多的
虽然似乎可以改成 deriveVar(String var) 但是鉴于只有x和y ，Term也没改hashmap就没多写（虽然是AI的）

3.新增了自定义递推函数 f{n}(x)
处理方法和f(x)类似虽然按道理来说要写Map<String, Map<Integer, Polynomial>> 但是只写了 Map<Integer, Polynomial> recursiveFuncMap
然后再是先在输入最终的表达式之后取出{}中最大的maxn就可以递推处理f{2}到f{maxn}的polynomial
然后Expr再弄个形参把recursiveFuncMap放进去就好