這篇文章是odersky談scala中的模式匹配的一段對話，我做了部分片段翻譯(不是連貫的):
模式可以巢狀，就像表示式巢狀，你可以定義深層的模式，通常乙個模式看起來就像乙個表示式。它基本上就是同一類事情。
它看起來像乙個複雜的物件樹構造表示式，只是漏掉了new關鍵字。事實上在scala當你構造乙個物件，你不需要new關鍵字
然後你可以在一些地方用變數做站位符替代物件樹上實際的東西。
本質上，當你需要通過外部來構造物件圖，模式匹配是必要的，因為你不能對這些物件新增方法
有很多場景的例子，xml是乙個，所有解析過的資料落入不同的分類。
舉例，乙個標準的場合是當你用編譯器解析抽象語法樹的時候模式匹配是必要的。
解構物件 (de-constructing objects)
bill venners: 你說模式像表示式，但它更像「逆表示式」，不同於插入值並得到結果(構造乙個物件的過程)，你放入乙個值，當它匹配，一串值彈出來。
martin odersky: 是的，它確實是反向構造，我可以通過巢狀的構造器來構造物件。我有乙個方法一些引數，通過這些引數可以構造出負責的物件結構。模式匹配正好相反，它從乙個複雜的物件結構中抽出原來用於構造這個物件的引數
可擴充套件性的兩個方向(two directions of extensibility)
擴充套件性的另乙個概念是資料結構相對固定，你不想改變它，但你想要用到的行為操作是開放的。你隨時都想要新增新的操作。
典型的例子是編譯器，編譯器用語法樹表達你的程式，只要你沒有改變你的語言，語法樹就不會變，一直都是同一顆樹
但編譯器想要這棵語法樹每天改變。明天你或許想到一種新的優化在遍歷樹的階段。
所以，你想採取的辦法是操作定義在你的語法樹外部，否則你要不斷的新增新方法
這個工作正確的方向，取決於你想在那個方向擴充套件，如果你想要擴充套件新的資料，你選擇經典的物件導向通過虛方法呼叫實現。如果你想保持資料固定，擴充套件新的操作，模式更適合。
實際上有乙個設計模式，不要和模式匹配混淆，在物件導向程式中稱為「訪問者模式」，也可以用物件導向的方式表達模式匹配的方式，基於虛方法委派的。
但實際中用visitor模式是非常笨重的，不能像模式匹配那樣輕鬆的做很多事。你應該終結笨重的vistors，同時在現代虛擬機器技術中也證明vistor模式遠沒有模式匹配有效。所有這些原因，我想應該為模式匹配定義一套規則
ps, 前段時間王垠同學在批判設計模式的一篇文章中，提到visitor模式就是模式匹配。
可以對比一下scala語言通過case class/extractor方式在語言級別支援模式匹配，與通過visitor模式來達到同樣的效果時的**差別。
文章** 併發程式設計網-ifeve.com
話說模式匹配 5 for表示式中的模式匹配
在for表示式中 for x collection 直覺上以為 x 就是個用於迭代每乙個元素的區域性變數。我們看一些例子 scala for i list 1,2,3 看看語法樹 scala tb.parse for i list 1,2,3 res2 tb.u.tree list 1,2,3 fo...
話說模式匹配 5 for表示式中的模式匹配
在for表示式中 for x collection 直覺上以為 x 就是個用於迭代每乙個元素的區域性變數。我們看一些例子 scala for i list 1,2,3 看看語法樹 scala tb.parse for i list 1,2,3 res2 tb.u.tree list 1,2,3 fo...
模式匹配 關於模式匹配的演算法實現2
參照我上篇部落格，只不過多了乙個識別率的演算法而已，還是參考歸併排序寫的，很簡單。上篇部落格位址 很多的解釋都在 裡面了，各位看看就明白了 author seen time 2015 09 20 include include include using namespace std struct p...