1700474267
}
1700474268
1700474269
}
1700474270
1700474271
其中，getExpStr是从键盘事件中获得的表达式，getValue方法是从键盘事件中获得表达式中的元素映射值，运行过程如下。
1700474272
1700474273
}
1700474274
1700474275
❑首先，要求输入公式。
1700474276
1700474277
请输入表达式：a+b-c
1700474278
1700474279
❑其次，要求输入公式中的参数。
1700474280
1700474281
请输入a的值：100
1700474282
1700474283
请输入b的值：20
1700474284
1700474285
请输入c的值：40
1700474286
1700474287
❑最后，运行出结果。
1700474288
1700474289
运算结果为：a+b-c=80
1700474290
1700474291
看，要求输入一个公式，然后输入参数，运行结果出来了！那我们是不是可以修改公式？当然可以，我们只要输入公式，然后输入相应的值就可以了，公式是在运行时定义的，而不是在运行前就制定好的，是不是类似于初中学过的“代数”这门课？先公式，然后赋值，运算出结果。
1700474292
1700474293
需求已经开发完毕，公式可以自由定义，只要符合规则（有变量有运算符合）就可以运算出结果；若需要扩展也非常容易，只要增加SymbolExpression的子类就可以了，这就是解释器模式。
1700474294
1700474295
1700474296
1700474297
1700474298
设计模式之禅 [:1700454049]
1700474299
设计模式之禅 27.2 解释器模式的定义
1700474300
1700474301
解释器模式（Interpreter Pattern）是一种按照规定语法进行解析的方案，在现在项目中使用较少，其定义如下：Given a language,define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.（给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。）
1700474302
1700474303
解释器模式的通用类图如图27-4所示。
1700474304
1700474305
1700474306
1700474307
1700474308
图27-4 解释器模式通用类图
1700474309
1700474310
❑AbstractExpression——抽象解释器
1700474311
1700474312
具体的解释任务由各个实现类完成，具体的解释器分别由TerminalExpression和NonterminalExpression完成。
1700474313
1700474314
❑TerminalExpression——终结符表达式
1700474315
1700474316
实现与文法中的元素相关联的解释操作，通常一个解释器模式中只有一个终结符表达式，但有多个实例，对应不同的终结符。具体到我们例子就是VarExpression类，表达式中的每个终结符都在栈中产生了一个VarExpression对象。