设计模式15:Interpreter 解释器模式(行为型模式)

Interpreter 解释器模式(行为型模式)

动机(Motivation)

在软件构建过程中,如果某一特定领域的问题比较复杂,类似的模式不断重复出现,如果使用普通的编程方式来实现将面临非常频繁的变化。

在这种情况下,将特定领域的问题表达为某种语法规则下的句子,然后构建一个解释器来解释这样的句子,从而达到解决问题的目的。

意图(Intent)

给定一个语言,定义它的文法的一种表示,并定义一种解释器,这个解释器用来解释语言中的句子。——《设计模式》GoF

中文数字转换为阿拉伯数字

    public class Context
    {
        private string statement;
        private int data;

        public Context(string statement)
        {
            this.statement = statement;
        }

        public string Statement
        {
            get
            {
                return statement;
            }
            set
            {
                statement = value;
            }
        }

        public int Data
        {
            get
            {
                return data;
            }
            set
            {
                data = value;
            }
        }
    }

    public abstract class Expression
    {
        protected Dictionary<string, int> table = new Dictionary<string, int>();

        public Expression()
        {
            table.Add("一", 1);
            table.Add("二", 2);
            table.Add("三", 3);
            table.Add("四", 4);
            table.Add("五", 5);
            table.Add("六", 6);
            table.Add("七", 7);
            table.Add("八", 8);
            table.Add("九", 9);
        }

        public virtual void Interpret(Context context)
        {
            if (context.Statement.Length == 0)
            {
                return;
            }

            foreach (string key in table.Keys)
            {
                int value = table[key];
                if (context.Statement.EndsWith(key + GetPostfix()))
                {
                    context.Data += value * Multiplier();
                    context.Statement = context.Statement.Substring(0, context.Statement.Length - GetLength() - 1);
                }

                if (context.Statement.EndsWith("零"))
                {
                    context.Statement = context.Statement.Substring(0, context.Statement.Length - 1);
                }
            }
        }

        public abstract string GetPostfix();
        public abstract int Multiplier();
        public virtual int GetLength()
        {
            return this.GetPostfix().Length;
        }
    }

    public class GeExpression : Expression
    {
        public override string GetPostfix()
        {
            return string.Empty;
        }
        public override int Multiplier()
        {
            return 1;
        }
        public override int GetLength()
        {
            return 0;
        }
    }
    public class ShiExpression : Expression
    {
        public override string GetPostfix()
        {
            return "十";
        }

        public override int Multiplier()
        {
            return 10;
        }
    }
    public class BaiExpression : Expression
    {
        public override string GetPostfix()
        {
            return "百";
        }
        public override int Multiplier()
        {
            return 100;
        }
    }
    public class QianExpression : Expression
    {
        public override string GetPostfix()
        {
            return "千";
        }
        public override int Multiplier()
        {
            return 1000;
        }
    }
    public class WanExpression : Expression
    {
        public override string GetPostfix()
        {
            return "万";
        }
        public override int Multiplier()
        {
            return 10000;
        }
        public override void Interpret(Context context)
        {
            if (context.Statement.Length == 0)
            {
                return;
            }

            List<Expression> tree = new List<Expression>();
            tree.Add(new GeExpression());
            tree.Add(new ShiExpression());
            tree.Add(new BaiExpression());
            tree.Add(new QianExpression());

            foreach (string key in table.Keys)
            {
                if (context.Statement.EndsWith(this.GetPostfix()))
                {
                    int temp = context.Data;
                    context.Data = 0;
                    context.Statement = context.Statement.Substring(0, context.Statement.Length - 1);

                    foreach (Expression exp in tree)
                    {
                        exp.Interpret(context);
                    }

                    context.Data = temp + this.Multiplier() * context.Data;
                }
            }
        }
    }

客户端调用代码:

        static void Main(string[] args)
        {
            string roman = "一千零五十万三千六百零二";

            Context context = new Context(roman);
            List<Expression> tree = new List<Expression>();
            tree.Add(new GeExpression());
            tree.Add(new ShiExpression());
            tree.Add(new BaiExpression());
            tree.Add(new QianExpression());
            tree.Add(new WanExpression());

            foreach (Expression exp in tree)
            {
                exp.Interpret(context);
            }

            Console.WriteLine("{0} = {1}", roman, context.Data);

            Console.ReadKey();
        }

输出:

一千零五十万三千六百零二 = 10503602

这段代码是将中文的数字转换为阿拉伯数字,如果按照面向过程的算法肯定是来截取字符串进行判断然后组合成正确的数字。在这段代码中则利用了Interpreter模式将位数进行表达式的封装。
首先看抽象Expression类,首先它封装了一个字典类,这个字典保存了中文的1-9的字符及其对应的阿拉伯数字。Interpret方法,遍历字典中的每个中文数字,并且判断截取中文数字加其后缀是否是结尾,如果是,则将对应的值乘以对应的位数,对应的位数是一个纯虚函数Multiplier,由派生类自己实现。在取得了对应的Expression的值后需要将中文数字语句中对应的字符串去掉。

在WanExpression中,我们重写了Interpret函数,这是由于万位数可以由千位以下的数字来描述,如三千二百万。重写Interpret函数的算法如下,先将千以下的表达式(包括千)加入一个List保存起来,然后遍历数字表,如果当前的表达式已经截取到万,那么先将已取得的数值用中间临时变量保存起来,将当前表达式的数字值置为0。然后将万以后的文字截取。再依次用List里面的千、百、十、个的Expression进行解释,最后取得的数值乘以万对应的位数加上临时变量。

在Main函数里使用List保存了个十百千万的表达式,依次用这些表达式来解析上下文。注意,解析的顺序是个十百千万的顺序。

结构(Structure)

Interpreter模式的几个要点

  • Interpreter模式的应用场合是Interpreter模式应用中的难点,只有满足“业务规则频繁变化,且类似的模式不断重复出现,并且容易抽象为语法规则的问题”才适合使用Interpreter模式。
  • 使用Interpreter模式来表示文法规则,从而可以使用面向对象技巧来方便“扩展”文法。
  • Interpreter模式比较适合简单的文法表示,对于复杂的文法表示,Interpreter模式会产生较大的类层次结构,需要求助于语法分析生成器这样的标准工具。

转载请注明出处:

作者:JesseLZJ
出处:http://jesselzj.cnblogs.com

时间: 2024-10-02 18:42:50

设计模式15:Interpreter 解释器模式(行为型模式)的相关文章

设计模式(15)--Interpreter(解释器模式)--行为型

1.模式定义: 解释器模式是类的行为模式.给定一个语言之后,解释器模式可以定义出其文法的一种表示,并同时提供一个解释器.客户端可以使用这个解释器来解释这个语言中的句子. 2.模式特点: 解释器模式在实际的系统开发中使用的非常少,因为它会引起效率.性能以及维护等问题,一般在大中型的框架型项目能够找到它的身影,比如一些数据分析工具.报表设计工具.科学计算工具等等,若你确实遇到“一种特定类型的问题发生的频率足够高”的情况,准备使用解释器模式时,可以考虑一下Expression4J.MESP(Math

php设计模式(一):简介及创建型模式

我们分三篇文章来总结一下设计模式在PHP中的应用,这是第一篇创建型模式. 一.设计模式简介 首先我们来认识一下什么是设计模式: 设计模式是一套被反复使用.容易被他人理解的.可靠的代码设计经验的总结. 设计模式不是Java的专利,我们用面向对象的方法在PHP里也能很好的使用23种设计模式. 那么我们常说的架构.框架和设计模式有什么关系呢? 架构是一套体系结构,是项目的整体解决方案:框架是可供复用的半成品软件,是具体程序代码.架构一般会涉及到采用什么样的框架来加速和优化某部分问题的解决,而好的框架代

23种设计模式介绍(三)---- 行为型模式

由于设计模式篇幅比较大,如果在一篇文章讲完所有的设计模式的话不利于阅读.于是我把它分为三篇文章 23种设计模式介绍(一)---- 创建型模式 23种设计模式介绍(二)---- 结构型模式 23种设计模式介绍(三)---- 行为型模式 设计模式都是比较抽象的概念,所以大家一定要确保看懂类图,而后再自己写代码加强记忆. 概述 行为型模式一共有11种: 模板方法模式(Template Method) 策略模式(Strategy) 命令模式(Command) 中介者模式(Mediator) 观察者模式(

【读书笔记】设计模式第6章:行为型模式2

本文主要分析了中介者模式.观察者模式.备忘录模式.访问者模式.状态模式.解释器模式,介绍它们的定义.优缺点.使用场景,以及实例代码.为了深刻地理解设计模式,最重要的还是动手编写代码. 我参照书中的例程重新构想了一些更加生动.易于理解的例子,希望大家喜欢. 代码可以通过以下链接进行浏览: http://git.oschina.net/caipeichao/java-design-pattern 这些代码都经过编译运行,保证没有错误. 中介者模式 定义 也叫调停者模式 用一个中介对象来封装一系列同事

设计模式(四) : 创建型模式--单例模式

单例模式的话,类图上来看是最简单的设计模式,就是一个类只能有一个自己的实例. 单例模式通常来说我们就有Lazy loading的和不是Lazy loading的.<java与模式>里面的关于这两种的类图,: 可以看到一个是现开始就实例话的,这样的话不符合我们的lazy loading,还有一种是在getinstance方法里头去new的,这样的话会有线程安全的问题,我们提供了双重检查锁. 下面看示意代碼︰ 1. 静态初始化: package com.javadesignpattern.Sing

设计模式(五) : 创建型模式--建造者模式

建造者模式的意图是将产品的内部表象和产品的生产过程分割开来. 类图: 示意性代码: package com.javadesignpattern.builder; public interface Builder { public void buildPart1(); public void buildPart2(); public Product retrieveProduct(); } ? 1 2 3 4 5 6 7 package com.javadesignpattern.builder;

23种设计模式介绍(一)---- 创建型模式

由于设计模式篇幅比较大,如果在一篇文章讲完所有的设计模式的话不利于阅读.于是我把它分为三篇文章 23种设计模式介绍(一)---- 创建型模式 23种设计模式介绍(二)---- 结构型模式 23种设计模式介绍(三)---- 行为型模式 由于设计模式都是比较抽象的概念,所以大家一定要确保看懂类图,而后再自己写代码加强记忆. 简介 设计模式分为三大类: 创建型模式,共五种:工厂方法模式.抽象工厂模式.单例模式.建造者模式.原型模式. 结构型模式,共七种:适配器模式.装饰器模式.代理模式.外观模式.桥接

设计模式(一): abstract factory抽象工厂模式 -- 创建型模式

1.定义 为创建一组相关或相互依赖的对象提供一个接口,而且无需指定他们的具体类. 2.适用场景 1.一个系统要独立于它的产品创建.组合和表示. 2.一个系统要由多个产品系列中的一个来配置. 3.当你要强调一系列相关的产品对象的设计以便进行联合使用. 4.当你提供一个产品类库,而只想显示它们的接口而不是实现. 3.评价 1.它分离了具体的类 2.它使得易于交换产品系列 3.它有利于产品的一致性 4.难以支持新种类的产品 5."开放-封闭"原则要求系统对扩展开放,对修改封闭.通过扩展达到增

设计模式(三) : 创建型模式--工厂方法模式

工厂方法模式区别与简单工厂模式主要在于,factory中对对象的实例化延迟到了子类的factory中, 这也是优于简单工厂的地方.下面看这个模式的类图(截自<java与模式>): 示意性代码: ? 1 2 3 4 5 6 7 package com.javadesignpattern.factorymethod; public interface Creator {          public Product fatcory(); } package com.javadesignpatte

设计模式(六):Singleton 单件模式 -- 创建型模式

1.定义 当需要控制一个类的实例数量且调用者可以从一个公共的访问点访问时. 2.适用场景 1. 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时. 2. 当这个唯一实例应该是通过子类化可扩展的,并且客户应该无需更改代码就能使用一个扩展的实例时. 3.评价 优点: 1. 对唯一实例的受控访问, 因为Singleton类封装它的唯一实例,所以它可以严格的控制客户怎样以及何时访问它. 2. 缩小名空间,Singleton模式是对全局变量的一种改进.它避免了那些存储唯一实例的全局变量污染名空