Head First设计模式之解释器模式

一、定义

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

主要解决:对于一些固定文法构建一个解释句子的解释器。

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

如何解决:构件语法树,定义终结符与非终结符。

二、结构

  组成:   

  AbstractExpression(抽象表达式):定义解释器的接口,约定解释器的解释操作。

  TerminalExpression(终结符表达式):用来实现语法规则中和终结符相关的操作,不再包含其它的解释器,如果用组合模式来构建抽象语法树的话,就相当于组合模式中的叶子对象,可以有多种终结符解释器。

  NonterminalExpression(非终结符表达式):用来实现语法规则中非终结符相关的操作,通常一个解释器对应一个语法规则,可以包含其它的解释器,如果用组合模式来构建抽象语法树的话,就相当于组合模式中的组合对象,可以有多种非终结符解释器。

  Context(上下文):它包含了解释器之外一些其他的全局信息;通常包含各个解释器需要的数据,或是公共的功能。

  Client(客户端):指的是使用解释器的客户端,通常在这里去把按照语言的语法做的表达式,转换成为使用解释器对象描述的抽象语法树,然后调用解释操作。

三、适用场景

1、可以将一个需要解释执行的语言中的句子表示为一个抽象语法树。

2、一些重复出现的问题可以用一种简单的语言来进行表达。

3、一个简单语法需要解释的场景。

四、优缺点

优点: 1、可扩展性比较好,灵活。 2、增加了新的解释表达式的方式。 3、易于实现简单文法。

缺点: 1、可利用场景比较少。 2、对于复杂的文法比较难维护。 3、解释器模式会引起类膨胀。 4、解释器模式采用递归调用方法。

五、实现

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace DesignPatterns.Interpreter
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(ReplyClient.ApplyContent("Y0001"));
            Console.WriteLine(ReplyClient.ApplyContent("y0002"));
            Console.WriteLine(ReplyClient.ApplyContent("N0003"));
            Console.WriteLine(ReplyClient.ApplyContent("n0004"));
        }
    }

    /// <summary>
    /// 回复内容
    /// </summary>
    public class ReplyContent
    {
        private string _ReplyText;

        public string ReplyText
        {
            get { return _ReplyText; }
            set { _ReplyText = value; }
        }
    }

    public abstract class InterPreter
    {
        public string ConvertContent(ReplyContent content)
        {
            if (content.ReplyText.Length == 0)
                return "请按规则回复审批短信.";
            return Excute(content.ReplyText);
        }

        public abstract string Excute(string key);
    }
    public class Approve : InterPreter
    {
        public override string Excute(string key)
        {
            if (key == "Y" || key == "y")
            {
                return "同意";
            }
            else if (key == "N" || key == "n")
            {
                return "拒绝";
            }
            else
            {
                return "回复内容有误,请重新回复.";
            }

        }
    }
    public class DocumentNum : InterPreter
    {
        public Dictionary<string, string> OddNum
        {
            get
            {
                Dictionary<string, string> OddID = new Dictionary<string, string>();
                OddID.Add("0001", "123890890892345");
                OddID.Add("0002", "123456717012345");
                OddID.Add("0003", "123456669012345");
                OddID.Add("0004", "123423444012345");
                OddID.Add("0005", "123467845345345");
                OddID.Add("0006", "123231234564345");
                OddID.Add("0007", "128797897867745");
                return OddID;
            }
        }

        public override string Excute(string key)
        {
            string value = null;
            if (OddNum.TryGetValue(key, out value))
            {
                return value;
            }
            else
            {
                return "没找到对应的单号.";
            }
        }
    }

    public class ReplyClient
    {
        public static string ApplyContent(string replayValue)
        {
            string result = string.Empty;
            string approvevalue = replayValue.Substring(0, 1);
            string oddIDvalue = replayValue.Substring(1, 4);

            ReplyContent content = new ReplyContent();
            content.ReplyText = approvevalue;
            InterPreter expression = new Approve();
            result = string.Format("你{0}", expression.ConvertContent(content));
            expression = new DocumentNum();
            content.ReplyText = oddIDvalue;
            result += string.Format("单号是{0}的申请.\n", expression.ConvertContent(content));
            return result;
        }
    }
}

参考

http://www.runoob.com/design-pattern/interpreter-pattern.html

http://www.cnblogs.com/JsonShare/p/7367535.html

http://www.cnblogs.com/springyangwc/archive/2011/05/05/2037146.html

欢迎阅读本系列文章:Head First设计模式之目录

时间: 2024-10-25 11:21:40

Head First设计模式之解释器模式的相关文章

大话设计模式_解释器模式(Java代码)

解释器模式:给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子. 简单描述:一个AbstractExpression类,多个子类,存在一个Interpret方法,转义Context对象的信息.客户端根据信息实例化不同的Expression类,并调用其转义方法(这个过程可以使用简单工厂+反射进行) 大话设计模式中的截图: 代码例子: 假设HTML代码解释器: (1)第一类标签<HTML>(开始)/<HEAD>(头信息)/<BODY&g

GOF23设计模式之解释器模式和访问器模式的理解

设计模式之解释器模式Interpreter      是一种不常用的设计模式      用于描述如何构成一个简单的语言解释器,主要用于使用面向对象语言开发的编译器和解释器设计.      当我们需要开发一种新的语言时,可以考虑使用解释器模式.      尽量不要使用解释器模式,后期维护会有很大麻烦.在项目中可以使用jruby,Groovy,java的js引擎来代替解释器的作用,弥补java语言的不足. 开发中常见的场景:      EL表达式的处理      正则表达式解释器      SQL语

设计模式之解释器模式(Interpreter)摘录

23种GOF设计模式一般分为三大类:创建型模式.结构型模式.行为模式. 创建型模式抽象了实例化过程,它们帮助一个系统独立于如何创建.组合和表示它的那些对象.一个类创建型模式使用继承改变被实例化的类,而一个对象创建型模式将实例化委托给另一个对象.创建型模式有两个不断出现的主旋律.第一,它们都将关于该系统使用哪些具体的类的信息封装起来.第二,它们隐藏了这些类的实例是如何被创建和放在一起的.整个系统关于这些对象所知道的是由抽象类所定义的接口.因此,创建型模式在什么被创建,谁创建它,它是怎样被创建的,以

C#设计模式:解释器模式(Interpreter Pattern)

一,C#设计模式:解释器模式(Interpreter Pattern) 1,解释器模式的应用场合是Interpreter模式应用中的难点,只有满足“业务规则频繁变化,且类似的模式不断重复出现,并且容易抽象为语法规则的问题”才适合使用解释器模式2,解释器设计模式每个解释的类有自己的规则,并且与其他业务规则不冲突 二,如下代码 using System; using System.Collections.Generic; using System.Linq; using System.Text; u

php设计模式之解释器模式

解释器设计模式用于分析一个实体的关键元素,并且针对每个元素都提供自己的解释或相应的动作. <?php /** * 解释器模式 */ class User { protected $_username; public function __construct($username) { $this->_username = $username; } public function getProfilePage() { $profile = "<h2>I like never

【GOF23设计模式】解释器模式 &amp; 访问者模式

来源:http://www.bjsxt.com/ 一.[GOF23设计模式]_解释器模式.访问者模式.数学表达式动态解析库式 1.解释器模式Interpreter  2.访问者模式Visitor 

【Unity与23种设计模式】解释器模式(Interpreter)

GoF中定义: "定义一个程序设计语言所需要的语句,并提供解释来解析(执行)该语言." 传统上,执行程序代码通常通过两种方式 第一种:编译程序 第二种:解释器 常见的使用解释器的程序设计语言 包含流行与网页设计领域中的脚本语言 如JavaScript.PHP.Ruby等 这些程序代码经过一般文本编辑器编写完成后放入指定的位置 就可以由应用程序中的解释器直接执行 包括Lua Unity中 编写好的脚本程序执行之前会被UnityEngine编译过 严格来说不算是解释器模式 但与十几年前的开

设计模式之解释器模式--- Pattern Interpreter

模式的定义 类型 行为类 模式的使用场景 优点 缺点 UML类图 角色介绍 模式的通用源码 输出结果 Android源码中的模式实现 杂谈 参考资料 (1).设计模式之禅-第27章 解释器模式 (2)解释器模式 https://github.com/simple-android-framework/android_design_patterns_analysis

折腾Java设计模式之解释器模式

解释器模式 解释器模式是类的行为模式.给定一个语言之后,解释器模式可以定义出其文法的一种表示,并同时提供一个解释器.客户端可以使用这个解释器来解释这个语言中的句子. 意图 给定一个语言,定义它的文法表示,并定义一个解释器,这个解释器使用该标识来解释语言中的句子. 主要解决 对于一些固定文法构建一个解释句子的解释器. 何时使用 如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言中的句子.这样就可以构建一个解释器,该解释器通过解释这些句子来解决该问题. 如何解