PHP設計模式——解釋器模式

聲明：本系列部落格參考資料《大話設計模式》，作者程傑。

        解釋器模式：Given a language, define arepresentation for its grammar along with an interpreter that uses therepresentation to interpret sentences in the language。給定一個語言,

定義它的文法的一種表示，并定義一個解釋器，該解釋器使用該表示來解釋語言中的句子。

       類圖：

             角色：  

       環境角色(PlayContent)：定義解釋規則的全局資訊。

       抽象解釋器(Empress)：定義了部分解釋具體實作，封裝了一些由具體解釋器實作的接口。

       具體解釋器(MusicNote)：實作抽象解釋器的接口，進行具體的解釋執行。

       核心代碼：（注意：需要開啟extension=php_mbstring.dll擴充）

        調用用戶端代碼：

       優點：

      解釋器是一個簡單文法分析工具，它最顯著的優點就是擴充性，修改文法規則隻要修改相應的非終結符表達式就可以了，若擴充文法，則隻要增加非終結符類就可以了。

       缺點：

      1.解釋器模式會引起類膨脹

      2.每個文法都要産生一個非終結符表達式，文法規則比較複雜時，就可能産生大量的類檔案，為維護帶來了非常多的麻煩。

     3.解釋器模式采用遞歸調用方法

     每個非終結符表達式隻關心與自己有關的表達式，每個表達式需要知道最終的結果，必須一層一層地剝繭，無論是面向過程的語言還是面向對象的語言，遞歸都是在必要條件下使用的，它導緻調試非常複雜。想想看，如果要排查一個文法錯誤，我們是不是要一個一個斷點的調試下去，直到最小的文法單元。

效率問題

     解釋器模式由于使用了大量的循環和遞歸，效率是個不容忽視的問題，特别是用于解析複雜、冗長的文法時，效率是難以忍受的。

        适用場景： 

       1、重複發生的問題可以使用解釋器模式

        例如，多個應用伺服器，每天産生大量的日志，需要對日志檔案進行分析處理，由于各個伺服器的日志格式不同，但是資料要素是相同的，按照解釋器的說法就是終結符表達式都是相同的，但是非終結符表達式就需要制定了。在這種情況下，可以通過程式來一勞永逸地解決該問題。

        2、一個簡單文法需要解釋的場景

     為什麼是簡單？文法規則越多，複雜度越高，而且類間還要進行遞歸調用，不是一般地複雜。想想看，多個類之間的調用你需要什麼樣的耐心和信心去排查問題。是以，解釋器模式一般用來解析比較标準的字元集，例如SQL文法分析，不過該部分逐漸被專用工具所取代。

         歡迎關注我的視訊課程，位址如下，謝謝。

<a target="_blank" href="http://edu.csdn.net/course/detail/602">   PHP面向對象設計模式</a>