引言
如何使用编程语言实现将中文的“三千五百二十六”转换成阿拉伯数字的3526呢？直觉方案可能是逐字符解析，但是你很快就能发现：
- “十”在不同位置含义不同：“二十”是20，而“十二”是12；
- 单位词（千、百、十）必须与前面的数字结合，例如“三百”=3×100；
- 零的省略规则：“一千零五”中的“零”不能遗漏，但“三千五百”中的“零”又需忽略。
如果直接硬编码if-else或正则表达式处理这些规则，代码会迅速膨胀成难以维护的“面条逻辑”，且每次新增单位（如“万”“亿”）都要修改核心逻辑，违反开闭原则。
那么，能否有一种设计模式，能把复杂的语法规则拆解成可以复用的对象，让代码像“搭积木”一样灵活扩展？这就是**解释器模式（Interpreter）**的用武之地——它通过将每个语法规则封装成独立的类，再像“拼图”一样组合这些类，最终实现从中文数字到阿拉伯数字的优雅转换。
概念
定义
解释器模式是一种行为型设计模式。解释器模式是指给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。简单来说，就是为了处理一种特定的语言或语法规则，创建一个解释器来解析和执行这种语言的句子或表达式。
结构与组成
- 抽象表达式（Abstract Expression）：定义了解释器的抽象接口，声明了一个抽象的解释方法，所有具体表达式类都需要实现这个方法。它是所有具体表达式的父类，为它们提供了统一的操作接口。
- 终结符表达式（Terminal Expression）：是抽象表达式的子类，代表了语言中的终结符。终结符是语言中不能再进一步分解的基本元素，比如在算术表达式中，数字就是终结符。终结符表达式实现了与终结符相关的解释操作。
- 非终结符表达式（Nonterminal Expression）：也是抽象表达式的子类，用于表示语言中的非终结符。非终结符是可以进一步分解为其他语法元素的符号，通常包含对其他表达式的引用。在算术表达式中，像加法、减法等运算符就是非终结符，它们需要结合其他表达式（可能是终结符或其他非终结符表达式）来进行解释和计算。
- 环境（Context）：这个角色用于存储解释器在解释过程中需要的一些全局信息和状态。它可以被各个表达式类访问，以便在解释过程中传递和共享数据，例如变量的赋值信息等。
工作原理
- 首先，需要根据要处理的语言的语法规则，构建出相应的抽象语法树。这棵树的节点由终结符表达式和非终结符表达式组成，它代表了输入的语言句子的语法结构。
- 然后，将需要解释的句子或表达式作为输入，从抽象语法树的根节点开始，按照深度优先或广度优先等遍历策略，依次对每个节点进行解释操作。在解释过程中，每个节点都会调用自身的解释方法，根据其类型（终结符或非终结符）执行相应的处理逻辑。
- 对于终结符表达式，直接根据其自身的含义进行解释和处理；对于非终结符表达式，则会递归地调用其包含的子表达式的解释方法，直到所有的节点都被解释完毕，最终得到整个句子或表达式的解释结果。
核心思想：
- 语法即对象：将每个语法规则封装成独立的类。
- 组合解释：通过递归组合对象，逐步解析最终结果。
示例
下面，我们尝试使用解释器模式来实现中文数字转阿拉伯数字。
类图
C++实现
#include <iostream>
#include <string>
#include <unordered_map>
#include <memory>
#include <vector>
// 上下文类，用于在解释过程中存储中间结果和最终结果
// 在解释器模式中，上下文对象提供了解释所需的环境和数据
class Context {
public:
int currentValue = 0; // 当前暂存的数字，用于临时存储解析到的单个数字
int total = 0; // 累计总和，存储最终转换后的阿拉伯数字
int sectionTotal = 0; // 每一级（万、亿等）的小计，处理万、亿等大单位时使用
};
// 抽象表达式类，是解释器模式的核心抽象部分
// 定义了所有具体表达式类都需要实现的解释操作接口
class AbstractExpression {
public:
// 虚析构函数，确保派生类对象能正确释放内存
virtual ~AbstractExpression() = default;
// 纯虚函数，具体表达式类需要实现该方法来对上下文进行解释操作
virtual void interpret(Context& context) = 0;
};
// 终结符表达式类：数字
// 表示中文数字字符，是解释器模式中的终结符，不能再进一步分解
class DigitExpression : public AbstractExpression {
private:
int digit; // 存储对应的阿拉伯数字
public:
// 构造函数，初始化数字
explicit DigitExpression(int d) : digit(d) {}
// 解释操作，将当前数字存储到上下文中
// 这是解释器模式中终结符表达式的具体解释逻辑
void interpret(Context& context) override {
context.currentValue = digit;
}
};
// 终结符表达式类：单位
// 表示中文计数单位，也是解释器模式中的终结符
class UnitExpression : public AbstractExpression {
private:
int unit; // 存储对应的单位值
public:
// 构造函数，初始化单位
explicit UnitExpression(int u) : unit(u) {}
// 解释操作，根据单位更新上下文的小计和总和
// 这是解释器模式中终结符表达式针对单位的具体解释逻辑
void interpret(Context& context) override {
if (unit >= 10000) {
// 处理万、亿等大单位
if (context.sectionTotal == 0 && context.currentValue == 0) {
context.currentValue = 1; // 处理单独的大单位（如"万"）
}
context.sectionTotal += context.currentValue;
if (unit == 100000000) {
// 遇到亿单位，将之前的总和与当前小节总和相加后乘以亿
context.total = (context.total + context.sectionTotal) * unit;
} else {
// 遇到万单位，将当前小节总和乘以万后累加到总和中
context.total += context.sectionTotal * unit;
}
// 处理完大单位后，重置小节总和
context.sectionTotal = 0;
} else {
// 处理十、百、千等小单位
if (context.currentValue == 0) {
context.currentValue = 1; // 处理类似"十"的情况
}
// 将当前数字乘以单位后累加到小节总和中
context.sectionTotal += context.currentValue * unit;
}
// 处理完后，重置当前暂存数字
context.currentValue = 0;
}
};
// 非终结符表达式类：组合表达式
// 用于组合多个终结符表达式，是解释器模式中的非终结符，可以包含其他表达式
class CombinedExpression : public AbstractExpression {
private:
std::vector<std::shared_ptr<AbstractExpression>> expressions; // 存储子表达式
public:
// 添加子表达式到组合表达式中
void addExpression(const std::shared_ptr<AbstractExpression>& expr) {
expressions.push_back(expr);
}
// 解释操作，依次解释每个子表达式，并处理最后的结果
// 这是解释器模式中非终结符表达式的具体解释逻辑，通过递归调用子表达式的解释方法来完成整体解释
void interpret(Context& context) override {
for (const auto& expr : expressions) {
expr->interpret(context);
}
// 处理最后的当前值（如个位数）和剩余的小计
context.total += context.sectionTotal + context.currentValue;
// 重置当前暂存数字和小节总和
context.currentValue = 0;
context.sectionTotal = 0;
}
};
// 中文数字字符到阿拉伯数字的映射
std::unordered_map<char, int> digitMap = {
{'零', 0}, {'一', 1}, {'二', 2}, {'三', 3}, {'四', 4},
{'五', 5}, {'六', 6}, {'七', 7}, {'八', 8}, {'九', 9}
};
// 中文计数单位到阿拉伯数字的映射
std::unordered_map<char, int> unitMap = {
{'十', 10}, {'百', 100}, {'千', 1000}, {'万', 10000}, {'亿', 100000000}
};
// 解析中文数字字符串并构建表达式树
// 此函数将输入的中文数字字符串解析为一系列的表达式对象，并组合成一个组合表达式
// 这是解释器模式中构建抽象语法树的过程
std::shared_ptr<AbstractExpression> parse(const std::string& chineseNumber) {
auto combinedExpr = std::make_shared<CombinedExpression>();
std::shared_ptr<AbstractExpression> prevDigitExpr;
for (size_t i = 0; i < chineseNumber.size(); ++i) {
char ch = chineseNumber[i];
if (digitMap.find(ch) != digitMap.end()) {
// 处理数字，创建数字表达式并添加到组合表达式中
prevDigitExpr = std::make_shared<DigitExpression>(digitMap[ch]);
combinedExpr->addExpression(prevDigitExpr);
} else if (unitMap.find(ch) != unitMap.end()) {
// 处理单位，创建单位表达式并添加到组合表达式中
combinedExpr->addExpression(std::make_shared<UnitExpression>(unitMap[ch]));
// 单位处理后，重置前一个数字表达式
prevDigitExpr.reset();
}
}
return combinedExpr;
}
// 中文数字转阿拉伯数字的主函数
// 此函数创建上下文对象，调用解析函数构建表达式树，然后对表达式树进行解释操作
// 这是解释器模式的整体执行流程，从输入的字符串到最终结果的转换过程
int chineseToArabic(const std::string& chineseNumber) {
Context context;
auto expr = parse(chineseNumber);
expr->interpret(context);
return context.total;
}
int main() {
std::vector<std::string> testCases = {
"一千二百三十四", // 1234
"十", // 10
"一百零五", // 105
"五千万", // 50000000
"一亿零一万零一" // 100010001
};
for (const auto& test : testCases) {
std::cout << "中文数字: " << test << " -> 阿拉伯数字: "
<< chineseToArabic(test) << std::endl;
}
return 0;
}
运行结果如下：
Java实现
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
// 上下文环境类
class Context {
public int currentValue;
public int total;
public int sectionTotal;
}
// 抽象表达式
abstract class Expression {
public abstract void interpret(Context context);
}
// 数字表达式（终结符）
class DigitExpression extends Expression {
private final int value;
public DigitExpression(int value) {
this.value = value;
}
@Override
public void interpret(Context context) {
context.currentValue = value;
}
}
// 单位表达式（终结符）
class UnitExpression extends Expression {
private final int unit;
public UnitExpression(int unit) {
this.unit = unit;
}
@Override
public void interpret(Context context) {
if (unit >= 10000) {
handleLargeUnit(context);
} else {
handleSmallUnit(context);
}
context.currentValue = 0;
}
private void handleLargeUnit(Context context) {
if (context.sectionTotal == 0 && context.currentValue == 0) {
context.currentValue = 1;
}
context.sectionTotal += context.currentValue;
if (unit == 100_000_000) {
context.total = (context.total + context.sectionTotal) * unit;
} else {
context.total += context.sectionTotal * unit;
}
context.sectionTotal = 0;
}
private void handleSmallUnit(Context context) {
if (context.currentValue == 0) {
context.currentValue = 1;
}
context.sectionTotal += context.currentValue * unit;
}
}
// 组合表达式（非终结符）
class CombinedExpression extends Expression {
private final List<Expression> expressions = new ArrayList<>();
public void addExpression(Expression expression) {
expressions.add(expression);
}
@Override
public void interpret(Context context) {
expressions.forEach(expr -> expr.interpret(context));
context.total += context.sectionTotal + context.currentValue;
context.currentValue = 0;
context.sectionTotal = 0;
}
}
// 解析器类
class Parser {
private static final Map<Character, Integer> DIGITS = new HashMap<>();
private static final Map<Character, Integer> UNITS = new HashMap<>();
static {
DIGITS.put('零', 0);
DIGITS.put('一', 1);
DIGITS.put('二', 2);
DIGITS.put('三', 3);
DIGITS.put('四', 4);
DIGITS.put('五', 5);
DIGITS.put('六', 6);
DIGITS.put('七', 7);
DIGITS.put('八', 8);
DIGITS.put('九', 9);
UNITS.put('十', 10);
UNITS.put('百', 100);
UNITS.put('千', 1000);
UNITS.put('万', 10_000);
UNITS.put('亿', 100_000_000);
}
public static Expression parse(String input) {
CombinedExpression root = new CombinedExpression();
for (int i = 0; i < input.length(); i++) {
char c = input.charAt(i);
if (DIGITS.containsKey(c)) {
root.addExpression(new DigitExpression(DIGITS.get(c)));
} else if (UNITS.containsKey(c)) {
root.addExpression(new UnitExpression(UNITS.get(c)));
}
}
return root;
}
}
// 客户端类
public class ChineseNumberConverter {
public static int convert(String chineseNumber) {
Context context = new Context();
Expression expression = Parser.parse(chineseNumber);
expression.interpret(context);
return context.total;
}
public static void main(String[] args) {
String[] testCases = {
"一千二百三十四",
"十",
"一百零五",
"五千万",
"一亿零一万零一"
};
for (String test : testCases) {
System.out.printf("%s -> %,d%n", test, convert(test));
}
}
}
解释器模式的优缺点
优点
1. 可扩展性强
- 新规则添加容易：当需要为解释的语言添加新的文法规则时，只需要创建新的表达式类并实现相应的解释方法即可，而不需要修改现有的代码结构。例如，在中文数字转阿拉伯数字的场景中，如果要增加新的计数单位（如 “兆”），可以创建一个新的表达式类来处理该单位，而不会影响到现有的数字和单位表达式类。
- 组合灵活：可以通过组合不同的表达式类来构建复杂的表达式，从而实现对复杂语言结构的解释。例如，在一个简单的算术表达式解释器中，可以将数字表达式、运算符表达式等组合起来，实现对不同类型算术表达式的解释。
2. 易于实现文法
- 直观表达文法规则：解释器模式将文法规则表示为类和对象，使得文法规则更加直观和易于理解。每个表达式类对应一个文法规则，通过解释这些表达式类可以完成对整个语言的解释。例如，在一个正则表达式解释器中，每个正则表达式的元素（如字符、量词、分组等）都可以用一个表达式类来表示，这样可以清晰地表达正则表达式的文法规则。
- 方便维护和修改：由于文法规则被封装在各个表达式类中，当需要修改或优化文法规则时，只需要修改相应的表达式类即可，不会对其他部分的代码产生影响。
3. 符合开闭原则
- 对扩展开放：可以通过创建新的表达式类来扩展解释器的功能，满足新的需求。例如，在一个脚本语言解释器中，如果要支持新的语法结构（如循环语句、条件语句等），可以创建相应的表达式类来实现这些语法结构的解释。
- 对修改关闭：在扩展解释器功能时，不需要修改现有的表达式类和解释器的核心逻辑，保证了系统的稳定性和可维护性。
缺点
1. 复杂性高
- 类的数量增加：对于复杂的文法，需要创建大量的表达式类来表示不同的文法规则，这会导致类的数量急剧增加，使代码结构变得复杂，难以理解和维护。例如，在一个完整的编程语言解释器中，可能需要创建数十个甚至数百个表达式类来处理各种语法结构。
- 抽象语法树构建复杂：解释器模式通常需要构建抽象语法树来表示输入的句子，对于复杂的文法，抽象语法树的构建过程会非常复杂，需要处理各种语法规则和优先级关系。
2. 执行效率低
- 递归调用开销大：解释器模式通常采用递归的方式来解释表达式，对于复杂的表达式，递归调用的深度会很大，导致性能下降。例如，在一个嵌套层次很深的算术表达式解释器中，递归调用会增加栈空间的使用和函数调用的开销。
- 解释过程重复：在解释过程中，可能会对相同的表达式进行重复解释，导致效率低下。例如，在一个包含多个相同子表达式的复杂表达式中，每个子表达式都需要被解释一次，这会浪费大量的计算资源。
3. 可维护性问题
- 调试困难：由于解释器模式涉及到多个表达式类和递归调用，当出现问题时，调试会变得非常困难。很难确定问题出在哪个表达式类或哪个解释步骤中。
- 规则修改影响大：虽然解释器模式符合开闭原则，但当文法规则发生较大变化时，可能需要对多个表达式类进行修改，这会增加维护的难度和风险。例如，当修改一个编程语言的语法规则时，可能需要同时修改多个表达式类来适应新的规则。
解释器模式的设计原则
1. 开闭原则（Open - Closed Principle）
- 概念：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。即当有新的需求出现时，应该通过扩展现有代码来实现，而不是修改已有的代码。
- 解释器模式中的体现：在解释器模式里，当需要为解释的语言添加新的文法规则时，只需创建新的表达式类并实现相应的解释方法，而不用修改现有的表达式类和解释器的核心逻辑。例如，在一个简单的算术表达式解释器中，原本只支持加法和减法运算，若要添加乘法和除法运算，只需创建新的乘法表达式类和除法表达式类，继承自抽象表达式类并实现其解释方法，而原有的加法和减法表达式类以及解释器的整体结构无需改动。
2. 单一职责原则（Single Responsibility Principle）
- 概念：一个类应该只有一个引起它变化的原因，即一个类只负责一项职责。
- 解释器模式中的体现：每个具体的表达式类都只负责解释一种特定的文法规则。比如在中文数字转阿拉伯数字的解释器中，数字表达式类（
DigitExpression）只负责处理中文数字字符到阿拉伯数字的转换，单位表达式类（UnitExpression）只负责处理中文计数单位的运算，它们各自承担单一的职责，使得代码的功能划分清晰，易于维护和扩展。
3. 里氏替换原则（Liskov Substitution Principle）
- 概念：子类可以替换其父类并且出现在父类能够出现的任何地方，而不会影响程序的正确性。
- 解释器模式中的体现：在解释器模式中，所有具体的表达式类（如数字表达式类、单位表达式类等）都继承自抽象表达式类。这些具体的表达式类可以替换抽象表达式类在解释器中的使用，并且能够正确地执行解释操作。例如，在组合表达式类（
CombinedExpression）中，存储的是抽象表达式类的引用，它可以存储任何具体表达式类的对象，并且在解释时能够正确调用具体表达式类的解释方法。
4. 依赖倒置原则（Dependency Inversion Principle）
- 概念：高层模块不应该依赖低层模块，二者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。
- 解释器模式中的体现：解释器模式中的高层模块（如解释器的上下文类）不直接依赖具体的表达式类，而是依赖抽象表达式类。具体的表达式类（如数字表达式类、单位表达式类等）也依赖抽象表达式类。这样，当需要更换或扩展具体的表达式类时，不会影响到解释器的上下文类和其他高层模块。例如，在中文数字转阿拉伯数字的解释器中，上下文类（
Context）和组合表达式类（CombinedExpression）都依赖抽象表达式类（AbstractExpression），而不是具体的数字表达式类或单位表达式类。
5. 接口隔离原则（Interface Segregation Principle）
- 概念：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
- 解释器模式中的体现：抽象表达式类定义的接口是最小化的，只包含一个解释方法（
interpret）。具体的表达式类只需要实现这个必要的接口方法，而不需要实现其他不必要的方法。这样，每个具体的表达式类只依赖于它真正需要的接口，避免了依赖过多不必要的接口而导致的代码耦合。
注意事项
1. 文法复杂性管理
- 类数量膨胀
- 问题：对于复杂的文法，需要创建大量的表达式类来表示不同的文法规则。例如，在实现一个完整的编程语言解释器时，要处理变量声明、函数调用、控制结构等多种语法规则，会导致类的数量急剧增加，使代码结构变得复杂，难以理解和维护。
- 解决办法：可以对文法进行合理的分层和分组，将相关的规则封装在一个模块或子系统中。同时，使用工厂模式来创建表达式对象，减少创建对象的代码重复。
- 抽象语法树构建困难
- 问题：解释器模式通常需要构建抽象语法树来表示输入的句子，对于复杂的文法，抽象语法树的构建过程会非常复杂，需要处理各种语法规则和优先级关系。
- 解决办法：可以借助成熟的解析工具（如 ANTLR、Yacc 等）来生成抽象语法树，这些工具可以帮助处理复杂的语法规则和优先级，减少手动编写解析代码的工作量。
2. 性能问题
- 递归调用开销
- 问题：解释器模式通常采用递归的方式来解释表达式，对于复杂的表达式，递归调用的深度会很大，导致性能下降，增加栈空间的使用和函数调用的开销。
- 解决办法：可以考虑使用迭代方式替代递归，或者使用尾递归优化技术。另外，对表达式进行缓存，避免对相同的子表达式进行重复解释，提高效率。
- 解释效率低下
- 问题：在解释过程中，可能会对相同的表达式进行重复解释，导致效率低下。
- 解决办法：可以实现一个表达式缓存机制，将已经解释过的表达式及其结果存储起来，当再次遇到相同的表达式时，直接从缓存中获取结果，避免重复计算。
3. 可维护性和可扩展性
- 调试困难
- 问题：由于解释器模式涉及到多个表达式类和递归调用，当出现问题时，调试会变得非常困难，很难确定问题出在哪个表达式类或哪个解释步骤中。
- 解决办法：添加详细的日志记录，在每个表达式类的解释方法中记录关键信息，如输入参数、中间结果等，方便调试时追踪问题。同时，使用调试工具（如调试器）来单步执行代码，定位问题所在。
- 规则修改影响大
- 问题：虽然解释器模式符合开闭原则，但当文法规则发生较大变化时，可能需要对多个表达式类进行修改，增加维护的难度和风险。
- 解决办法：在设计表达式类时，尽量遵循单一职责原则，使每个类的功能尽可能单一。同时，建立良好的测试用例集，在修改规则后进行全面的测试，确保系统的正确性。
4. 安全性
- 输入验证
- 问题：如果解释器直接处理用户输入，可能会面临恶意输入导致的安全问题，如代码注入、栈溢出等。
- 解决办法：在接收用户输入时，进行严格的输入验证，过滤掉非法字符和危险的输入。同时，对解释过程进行限制，如设置递归深度上限，防止栈溢出。
5. 适用场景选择
- 不适合简单文法
- 问题：对于简单的文法，使用解释器模式可能会引入过多的复杂性，得不偿失。
- 解决办法：如果文法比较简单，可以采用更简单直接的方法来实现，如使用正则表达式或简单的字符串处理逻辑。只有当文法比较复杂且需要经常扩展和修改时，才考虑使用解释器模式。
应用场景
解释器模式适用于需要对特定语言或文法进行解释和处理的场景，以下是一些常见的应用场景：
1. 编程语言解释器
- 场景描述：在开发编程语言的解释器或编译器时，解释器模式可以用来解析和执行程序代码。编程语言具有复杂的语法规则，如变量声明、函数调用、控制结构等，解释器模式可以将这些语法规则抽象成不同的表达式类，通过解释这些表达式类来实现对程序代码的解释和执行。
- 示例：Python、Ruby 等脚本语言的解释器在处理代码时，会将代码解析成抽象语法树（AST），每个节点可以看作是一个表达式，解释器通过递归地解释这些表达式来执行程序。
2. 数学表达式计算
- 场景描述：在需要对数学表达式进行计算的场景中，解释器模式可以用来解析和计算各种数学表达式，如四则运算、三角函数、指数运算等。可以将数字、运算符等抽象成不同的表达式类，通过组合这些表达式类来构建复杂的数学表达式，并进行计算。
- 示例：在一个科学计算器应用中，用户输入的数学表达式可以使用解释器模式进行解析和计算。例如，输入 “3 + 5 * 2”，解释器会将其解析为相应的表达式并计算出结果 13。
3. 正则表达式引擎
- 场景描述：正则表达式是一种用于匹配和处理文本的强大工具，正则表达式引擎可以使用解释器模式来解析和执行正则表达式。正则表达式的各种元素（如字符、量词、分组等）可以抽象成不同的表达式类，通过解释这些表达式类来实现对文本的匹配和处理。
- 示例：在编程语言中，如 Java、Python 等，都提供了正则表达式库，这些库的实现可以基于解释器模式。例如，使用正则表达式 “\d+” 来匹配一个或多个数字，正则表达式引擎会将其解析为相应的表达式并对输入的文本进行匹配。
4. 配置文件解析
- 场景描述：在软件开发中，经常需要使用配置文件来存储程序的配置信息，如数据库连接信息、服务器配置等。配置文件通常有自己的语法规则，解释器模式可以用来解析这些配置文件，将配置信息转换为程序可以使用的数据结构。
- 示例：常见的配置文件格式如 XML、JSON 等，都有自己的语法规则。可以使用解释器模式来解析这些配置文件，将其中的配置信息提取出来并应用到程序中。例如，一个 Java 程序可以使用解释器模式解析 XML 配置文件，获取数据库连接信息并建立数据库连接。
5. 规则引擎
- 场景描述：规则引擎用于根据预定义的规则对数据进行处理和决策。规则通常由条件和动作组成，解释器模式可以用来解析和执行这些规则。将规则的条件和动作抽象成不同的表达式类，通过解释这些表达式类来判断条件是否满足，并执行相应的动作。
- 示例：在一个电商系统中，规则引擎可以根据用户的购买行为和商品信息来判断是否满足促销条件，并执行相应的促销活动。例如，规则 “如果用户购买的商品总价超过 1000 元，并且购买的商品数量超过 5 件，则给予 10% 的折扣” 可以使用解释器模式进行解析和执行。
扫一扫
7740
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
