跳到主要內容

解譯器模式 (Interpreter Pattern)

        解譯器模式簡單來說就是把一句有特殊規則的語句,透過解釋器將它真正的意思表現出來。相信有學過 Context-free grammar (CFG),Backus–Naur form (BNF),或是 Compiler 相關程的人會比較了解這個模式 (不是我,我早就忘光了…)。不知道上面術語的人,還是可以透過接下來的介紹來稍微了解這個模式。先來看一下這個模式的正式定義及類別圖:

定義一個語言與其文法,使用一個解譯器來表示這個語言的敘述

Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language




  • Context 通常是指待解譯的語句
  • AbstractExpression 是所有規則都要實作的介面
  • TerminalExpression 是指無法再展開的規則,算是最小單位的規則
  • NonterminalExpression 是指可以再展開的規則,可以展開成 NonterninalExpression 和 TerminalExpression 的組合
        從類別圖可以看到,語法可能可以一直展開,這時就可以用語法樹來表示,而語法樹以程式來表達的話,就可以使用合成模式。而通常比較正式的語法會用 BNF 來表示,如下:

expression ::= plus | minus | variable | number
plus ::= expression expression '+'
minus ::= expression expression '-'
variable ::= 'a' | 'b' | 'c' | ... | 'z'
digit = '0' | '1' | ... | '9'
number ::= digit | digit number

每個語法都會定義一個類別,如 plus,minus,variable,number。但這篇文章主要是介紹解譯器模式,因此不會深入討論如何定義正式的語法。

        接著來看個簡單的例子吧 (真的是很簡單…)。假設你有一個語句如 a123 或是 B456,你的解譯器當看到第一個字是字母且第一個字母是小寫時,要把句子後面的數字乘以 2。當第一個字是字母且第一個字母是大寫時,要把後面的數字除以 2,程式碼可以如以下表示:
// 存放要解譯的語句
public class Context {

    private String mContext;
    public Context(String str)
    {
        mContext = str;
    }

    public String getContext()
    {
        return mContext
    }
}

// 解譯器要實作的介面
public interface Expression
{
    public int interpret(String expression);
}

// 解譯第一個字母是小寫的語句的解譯器
public class ExpressionImplA implements Expression
{
    @Override
    public int interpret(String expression)
    {
        String str = expression.substring(1, expression.length())
        return Integer.valueOf(str) * 2;
    }
}

// 解譯第一個字母是大寫的語句的解譯器
public class ExpressionImplB implements Expression
{
    @Override
    public int interpret(String expression)
    {
        String str = expression.substring(1, expression.length())
        return Integer.valueOf(str) / 2;
    }
}

public class Main {

    public static void main(String[] args)
    {
        Context context = new Context("a123 B456");
        Expression expression = null;
        for(String sentence : context.getContext().split(" "))
        {
            String first = sentence.substring(0, 1);
            if(first.matches("[a-z]"))
            {
                expression = new ExpressionImplA();
            }
            else
            {
                expression = new ExpressionImplB();
            }

            /*
             * 會輸出:
             * 246
             * 228
             */
            System.out.println(expression.interpret(sentence));
        }
    }
}

        最後簡單說明一下這個模式的優缺點吧。解釋器模式的特性就是每個語法規則都設計相對應的類別,除了方便實踐語法外,也容易改變或擴充語法,因此當你需要實踐一個簡單語言時,而且簡單比效率重要時,就適合使用這個模式。不過缺點就是語法規則多,語法變得複雜時,類別也相對的會變多,這時候使用剖析器 / 編譯器的產生器會比較適合。

        在實際應用上,Java 的 PatternSimpleDateFormate 算是有用到這個模式,有興趣的以參考看看。

參考資料

        深入淺出設計模式(Head First Design Patterns)
        Interpreter pattern
        解譯器模式 Interpreter Pattern

留言

  1. void -> int
    b456 - > B456
    結果才會是228
    expresion -> expression
    少一個s

    回覆刪除

張貼留言

這個網誌中的熱門文章

訪問者模式 (Visitor Pattern)

        假設你設計一個系統,其中會有一些相似類別,類別中都有某些方法內容相似,但還是需要判斷目前要做事的是哪個類別才能呼叫對應的適當類別。通常遇到這種情情,在 Java 中最直接的做法就是使用 instanceof 關鍵字來判斷,如以下的簡單範例: public interface CarComponent { public void printMessage(); } public class Wheel implements CarComponent { @Override public void printMessage() { System.out.println("This is a wheel"); } // 這是 Wheel 跟 Engine 不同的方法 public void doWheel() { System.out.println("Checking wheel..."); } } public class Engine implements CarComponent { @Override public void printMessage() { System.out.println("This is a engine"); } // 這是 Wheel 跟 Engine 不同的方法 public void doEngine() { System.out.println("Testing this engine..."); } } public class Car { private List mComponents; public Car() { mComponents = new ArrayList<carcomponent>(); } // 有些時候我們還是需要針對不同類別去做不同的事情 public void setComponent(CarCompon...

裝飾者模式 (Decorator Pattern)

        假如你有一間飲料店, 目前只有賣幾種咖啡。因為生意很好, 因此想更換菜單…         以下是目前菜單的類別圖:         簡單說明此類別圖, cost() 是抽象的, 子類別要實作自己的 cost() 來告知飲料的價格。         買咖啡時, 也可要求要加料, 例如牛奶(Milk)、摩卡(Mocha,就是巧克力口味)。這樣的新類別要如何設計呢 ? 看起來是不能直接新增所需的子類別, 例如 EspressoWithMilk, EspressoWithMilkAndMocha, DarkRoastWithMilk, DarkRoastWithMilkAndMocha… 這樣加下去, 日後飲料跟配料越來越多時, 類別也就越多, 這實在不是個好設計。         換個方式設計呢, 在 Beverage 裡面加入所有的配料如何 ? 這樣好像也不太好, 未來要是配料有更動, Beverage 程式碼就要重寫, 而未來要是有新口味的飲料時, 有些配料就不太合理 ( 薑茶加摩卡 ? ), 更麻煩的是, 無法應付機車的客人 (例如要加 3 份牛奶)。這時候裝飾者模式就能上場啦。在介紹裝飾者模式前, 先說明其設計守則: 類別應該開放, 以便擴充 ; 應該關閉, 禁止修改。         我們的目標是允許類別容易擴充, 在不修改現有程式碼的情形就能搭配新的行為。這樣的設計具有彈性, 可以接受新功能以達到改變需求的目的。這看起來好像有點矛盾, 但是的確有一些技術可以在不直接修改程式碼的情形下進行擴充, 如裝飾者模式。         這時候應該有人會問: 那是不是以後我的專案架構設計都遵循這個守則就是好設計了 ? 答案是不太可能, 也沒這必要, 就算做得到, 也可能是浪費, 容易導致程式碼複雜且難以理解。只需小心選擇哪些部分未來會擴充, 這些部份遵循這個設計守則即可。         接下來...

狀態模式 (State Pattern)

        如果今天你要設計一台如下圖的糖果機,你會怎麼設計呢?         有上過資訊相關課程的人,應該不難從上圖聯想到 狀態圖 ,上圖中每個圓圈都是一個狀態,而每個箭頭就代表狀態的轉換。有了這個概念後,把它轉成程式就不難了: public class CandyMachine { // 以下四個值表示糖果機會用到的狀態 final static int SOLD_OUT = 0; final static int NO_COIN = 1; final static int HAS_COIN = 2; final static int SOLD = 3; // 需要有一個變數來記錄目前的狀態 // 初始設為賣完, 因為一開始機器裡沒糖果 int mState = SOLD_OUT; // 也要有另一個變數記錄目前剩多少顆糖果 int mCount = 0; public CandyMachine(int count) { mCount = count; // 機器內有糖果的話就跳到沒投錢的狀態, // 表示糖果機在等人投錢 if(mCount > 0) { mState = NO_COIN; } } // 當投錢時會執行這個方法 public void insertCoin() { if(mState == HAS_COIN) { System.out.println("You can't insert another coin"); } else if(mState == NO_COIN) { mState == HAS_COIN; System.out.println("You inserted a coin"); } ...