Java设计模式-解释器模式

解释器模式

1.解释器模式

解释器模式,给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子。

其实解释器模式很简单的,就是一个翻译的过程,就像翻译软件,你给程序输入中文,翻译软件把中文翻译为英文。而这个软件就是解释器。

2.代码示例

2.1Context类

Context类包含解释器之外的一些全局信息

java 复制代码
public class Context {
    private String input;
    private String output;

    public String getInput() {
        return input;
    }

    public void setInput(String input) {
        this.input = input;
    }

    public String getOutput() {
        return output;
    }

    public void setOutput(String output) {
        this.output = output;
    }
}

2.2AbstractExpression类

AbstractExpression声明一个抽象的解释操作,这个接口为抽象语法树中所有节点所共享

java 复制代码
public abstract class AbstractExpression {
    public abstract void interpret(Context context);
}

2.3TerminalExpression类

TerminalExpression实现与文法中的终结符相关联的解释操作。实现抽象表达式中所要求的接口。

java 复制代码
public class TerminalExpression extends AbstractExpression{
    @Override
    public void interpret(Context context) {
        System.out.println("终端解释器");
    }
}

2.4NonTerminalExpression类

NonTerminalExpression为问法中的非终结符实现解释操作

java 复制代码
public class NonTerminalExpression extends AbstractExpression{
    @Override
    public void interpret(Context context) {
        System.out.println("非终端解释器");
    }
}

2.5测试类

java 复制代码
public class MainApp {
    public static void main(String[] args) {
        Context context = new Context();
        List<AbstractExpression> list = new ArrayList<>();
        list.add(new TerminalExpression());
        list.add(new NonTerminalExpression());
        list.add(new TerminalExpression());
        list.add(new TerminalExpression());

        for (AbstractExpression expression : list) {
            expression.interpret(context);
        }
    }
}

运行结果

终端解释器

非终端解释器

终端解释器

终端解释器

3.总结

解释器模式需要解决的是,如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器,改解释器通过解释这些句子来解决该问题。

当一个语言需要解释执行,并且你可以将该语言中的句子表示为一个抽象语法树的时候,就可以使用解释器模式。

用了解释器模式,就意味着可以很容易地改变和扩展文法,因为改模式使用类来表示文法规则,可以使用继承来改变或扩展该文法。也比较容易实现文法,因为定义抽象语法树中各个节点的类的实现大体类似,这些类都易于直接编写。

当然,解释器模式也有不足的,解释器模式为文法中的每一条规则至少定义了一个类,一次包含许多规则的文法可能难以管理和维护。建议当文法非常复杂时,使用其他技术如语法分析程序或编译器生成器来处理。

其实解释器模式我感觉不必拘泥于什么样的数据结构,只要能体现出解释器模式的作用即可。比如上面的示例代码,可能看着一头雾水,不用紧张,我也看不懂。但是只要我们知道解释器的意思,它可以用来干什么,在什么情况下使用它,就行了,至于数据结构是否是标准的解释器模式这个就无关紧要了。

设计模式的学习,更多的是要学习每一种设计模式背后的设计思想,不必拘泥于每一种模式的数据结构是否标准,只要自己的设计,能够总体上满足开闭原则,易于扩展维护等等,那就是一个好的设计模式。

相关推荐
老板一杯拿铁19 分钟前
Java 八股文面试详解:从基础到进阶的全面梳理
java·面试
const_qiu20 分钟前
第 2.5 章 2.5.4-2.5.5:JWT 双 Token 与声明式权限守卫
java·人工智能
bug菌22 分钟前
一个周末就想把短链服务推到 10 万 QPS,真能靠加 Redis 做到吗?
java·redis·go
撸串-研究生23 分钟前
springboot福利院管理系统73979
java·spring boot·后端·福利院管理系统
不得了zz1 小时前
04-Spring AI Alibaba ReactAgent 生产级实践:工具调用、结构化输出、HITL 与上下文管理
java·ai编程·springaialibaba
猿究院_夏燊2 小时前
SpringMVC 到底是怎么干活的?
java·网络·职场和发展
鶴哥只手遮天2 小时前
Spring Framework 7.0.9 深度剖析-05-配置元数据解析:XML、注解与 JavaConfig
java·后端·开源
NGINX开源社区2 小时前
与我们交流:NGINX Gateway Fabric 与 NGINX Ingress Controller 社区会议
java·服务器·前端
鶴哥只手遮天2 小时前
Spring Framework 7.0.9 深度剖析-16-异步与调度
java·后端·开源
十年Java程序媛2 小时前
Java 多线程基础与锁机制|进程线程、synchronized、volatile、Lock 面试全梳理
java·spring boot·面试