設計模式筆記(9 INTERPRETER & ITERATOR)

INTERPRETER(解釋器)
適用性：
當有一個語言需要解釋執行，並且你可以將語言中的句子表示爲一個抽象語法樹時，可使用解釋器模式。

思考：
一個常見使用情況當然是操縱一種程序語言，例如JavaScript，Python。這個時候，我們通常使用一個腳本引擎庫來實現解釋器。然而，並不是所有語言都是程序語言，解釋器模式更多的時候可以用來處理非程序語言，例如正則表達式。語言的規則也可以簡單，也可以複雜，通常，解釋器是一個引擎。XML的解析引擎，也可以看做解釋器模式。因此，可以認爲：針對程序語言的實現，是一種強化的實現；針對簡單到極點的語言（表格），可以看作是退化的實現。解釋器的目的是希望通過數據（語言）來推動邏輯。一般意義上的數據缺乏足夠的表現力，因此不具備顯著地改變程序行爲的能力。
INTERPRETER並非高不可及，完全可以在一些平凡的地方發揮作用。


ITERATOR(迭代器)
適用性：
訪問一個聚合對象的內容而無需暴露它的內部表示。
支持對聚合對象的多種遍歷。
爲遍歷不同的聚合結構提供一個同一的接口。

思考：
    熟悉STL的人看到這個模式應該發出會心一笑，是的，STL的迭代器正是迭代器模式的運用。迭代器總是和聚合聯繫在一起，提到迭代器，就需要關注兩個方面：一是訪問誰，二是怎麼訪問。
    對於一個迭代器對象，它需要知道訪問的是什麼聚合對象，當然這種“知道”並沒有固定的方式。一種方式是，在迭代器對象內部記錄關聯的對象引用，另一種方式是記錄迭代器在聚合中所處的位置。STL的迭代器採用的是後一種方法。前一種方法界面簡單，而且，有可能有效地對付迭代器失效問題。後一種迭代器更靈活，但是，所有保證正確的責任落在了程序員身上。還有一種內部迭代器，就是把迭代要完成的過程代碼作爲參數，讓一個方法幫助完成迭代過程，這種方式更優雅、簡單和安全，但是，也更不靈活。對於C++來說，尤其如此。即使有boost.lambda幫忙，也仍然過於複雜。不過，如果C++支持閉包、嵌套函數，我想也許情況會好一點。
    另一個問題是如何訪問。迭代器的訪問方式一般是預定義的，當然，你也可以設計一個可以定製其訪問方式的迭代器來。迭代器並不意味着要訪問聚合中的所有元素，也個聚合也可以提供多種迭代器。對於一個樹而言，可以提供前序遍歷的迭代器，也可以提供中序遍歷的迭代器。你也可以爲一個線性聚合提供訪問奇數元素的迭代器和訪問偶數元素的迭代器，雖然我沒有想出來這有什麼用處。