BUAA-OO-表达式解析与求导
解析
按照常规,解析这一部分我们分为词法分析与语法分析。当然由于待解析的字符串较简单,词法分析器和语法分析器不必单独实现。
词法分析器
按照常规,我们先手写一个词法分析器,而不使用正则表达式。
词法分析器:读取字符流,产生标记流。它聚合字符形成单词,并应用一组规则来判断每个单词在源语言中是否合法,如果合法则为其分配一个语法范畴,产生一个标记。
我们的词法分析器行为如下:
- 如果 当前输入有定义,则 为其产生一个标记(token, token value)。譬如:当前输入是"+114514",则为其产生标记(Num, +114514);当前输入是"*",则为其产生标记(Op,*),诸如此类。
- 如果 当前的输入无定义,则 抛出错误。譬如:当前输入是"y",则抛出错误。
可能你已经发现,这个词法分析器并不能很好地满足我们的需求:当输入为"+114514"时,如何判断是"+",或是"+114514"呢?
这里我们需要额外介绍一个概念:lookahead,即提前看多个字符。由于有一个或多个标记是以相同的字符开头的,仅凭当前的字符无法确定具体应该解释为哪个标记,所以只能再向前查看字符。以"+114514"为例,在解析到"+"之后,还需要向前查看一个字符"1",此时就能够确定当前输入对应的标记种类应为 Num。
具体实现
完成词法分析器的行为定义之后,我们开始进行更为详尽的设计。
首先,由定义,我们可以得到我们所需的标记种类:
/**
* Num : 数字
* Op : 运算符
* Sin : Sin函数
* Cos : Cos函数
* X : 幂函数
* LP : 左括号
* RP : 右括号
* NULL: 字符流末尾
*/
enum TokenType {
Num, Op, Sin, Cos, X, LP, RP, NULL
}
接下来就是枯燥的枚举:
void getTok() {
token="";
tokenType = TokenType.NULL;
// consume blank char
{ /* some code */ }
// reach the end
{ /* some code */ }
switch (currentCharacter) {
case 'x' :
/* some code */
case 's' :
/* some code */
default :
throw new someKindOfException();
}
词法分析器部分告一段落。
语法分析器
文法
首先根据定义给出文法
<expr> ::= <expr> + <term>
| <expr> - <term>
| <term>
<term> ::= <term> * <factor>
| <factor>
<factor> ::= (<expr>)
| Num
| sin(<factor>)
...
在文法中出现了两种符号,一种是被<>包围的非终结符,如<expr>,可以用 ::= 右侧的式子替代;另一种是没有出现在 ::= 左侧的终结符,如 Num,一般对应于词法分析器输出的标记。
解析过程
然后是递归下降的解析过程,关于什么是递归下降,稍后会进行解释。以 1*(2+3) 为例
<expr> => <expr>
=> <term> * <factor>
=> <factor> |
=> Num (3) |
=> (<expr>)
=> <expr> + <term>
=> <term> |
=> <factor> |
=> Num (2) |
=> <factor>
=> Num (3)
整个解析的过程是在不断对非终结符进行替换(向下),直到遇到了终结符(底)。在解析的过程中,有的非终结符,如<expr>被递归地使用了。
递归下降:从起始非终结符开始,不断地对非终结符进行分解,直到匹配输入的终结符。
可以看出,整个解析的过程和我们的文法是十分相近的,我们可以很容易地将文法直接转换成实际的代码,只需为每个非终结符定义一个对应的函数。不过,很显然我们的文法是没有办法直接翻译成实际代码的,这是编译原理的内容了,此处不再赘述。
除了递归下降以外,还可以选择使用自底向上的方法进行语法分析,由于是手写语法分析器,我们不考虑采用自底向上。
语法树
根据解析过程,我们很自然地会想到树这种数据结构。一个简略的语法树如下
expr
/ | \
term term ...
/ | \
num sin cos ...
具体实现
以下是根据文法直接翻译的一个不可能的实现。
Expr parseExpr() {
Expr result = new Expr();
loop {
// create a node
Term term = parseTerm();
// attach
result.addNode(term);
}
return result;
}
Term parseTerm() {
Term result = new Term();
loop {
// create a node
Factor factor = parseFactor();
// attach
result.addNode(factor);
}
return result;
}
Factor parseFactor() {
Factor result = new Factor();
loop {
{/* some code */}
}
return result;
}
至此,已完成对输入字符串的解析。
求导
根据字符串解析的方法,我们求导的方式也是自顶向下的。
以下是根据语法树得到的一个不可能的实现
Expr exprDiff() {
Expr result = new Expr();
for (term : termContainer) {
result.addNode(termDiff(term));
}
return result;
}
Term termDiff() {
Term result = new Term();
for (factor : factorContainer) {
result.addNode()
}
return result;
}
Factor factorDiff() {
return diff();
}
个人实现分析
度量分析
UML类图:
Method Metrics:
Class Metrics:
以上为第三次表达式解析与求导作业的UML图和代码指标度量。可以看得出来其中不乏有许多设计和算法问题,譬如
- 没有另外设置一个Factor的抽象类或者接口,而是将各种Functions直接继承自Expr
- 模块间的耦合度高,没有合理地设计每个类暴露的接口形状
- 没有在创建树结点时存储其相应的HASH值,而是在每次进行相等性判断时都进行一次递归运算,大大提高了时间复杂度
- 在判断相等时用的是简单的遍历比较,而不是设计一个可以避免碰撞的HASH函数
设计模式
简单地运用了工厂模式,将各种Functions的创建托管至Expr。但是这并不是一个好的设计,应该如上述,Expr和各种Functions都继承自Factor抽象类,然后创建一律托管至FactorFactory。否则Functions实现的改变可能会影响Expr实现的改变,这将增大迭代开发和后期维护的复杂度。