【模式定義】
在乙個方法中定義乙個演算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類可以在不改變演算法結構的情況下，重新定義演算法中的某些步驟。
【解決問題】
泡咖啡，泡茶。其實兩者都差不多，具體流程類似，只有部分內容不同。
【最初實現】
定義兩個不同的類：coffee、tea。他們的**相似，有很多重複的**，不是乙個好的實現。應該把相同的部分抽取出來，放在乙個基類。
【逐步改善】 1
．部分抽取
----
這樣，在各個子類裡，還是要覆蓋這些它的流程，重新實現不同的部分。但是，流程也是類似的，沒有必要再子類裡實現流程的邏輯控制。這部分繼續抽象。 2.
再次抽取
----
把控制流程也抽取出來，並定義為final的，不允許子類改變流程（符合下面說到的設計原則）。需要由子類實現的，定義為abstract，而共有的方法，在父類裡實現即可。
再來兩個tea、coffee子類繼承這個基類，並實現抽象的方法。 3.
新增鉤子
我們可以有「預設不做事的方法」，我們成為「鉤子」（hook）。子類可以視情況是否覆蓋它們。如上面的函式。通常是空的預設的實現（只是返回true，什麼也不做）。如果我們需要調料，那麼，在子類裡，可以這麼實現這個方法，進而提供自己的功能。
【設計原則】
好萊塢原則——別呼叫（打**給）我們，我們會呼叫（打**給）你。
----
換句話說，允許低層元件將自己掛鉤到系統上，但是高層元件會決定什麼時候和怎麼使用這些低層元件。
模板模式符合這樣的原則。（工廠模式、觀察者模式也符合。）基類控制整個沖泡的演算法，只有在需要到具體的實現時，才會呼叫到子類。子類只是簡單地提供一些實現細節。而外部的客戶，也只依賴與基類抽象，而不依賴具體的tea或coffee。減少整個系統的依賴。
【具體實現】 1.
排序 ----
的確很荒野…基本思想是這樣的，我們提供的是低層的具體實現，但整體的流程是有高層決定的。
2.swing jframe
的paint（）函式
----
當需要時，過載，實現它。鉤子。
----
提供了好多的鉤子，init（），start（），stop（），等等。也是需要時，就是實現這些鉤子。具體的流程，怎麼處理，在基類裡實現。
【與策略模式比較】
按我的理解。策略模式，是演算法的組合。整個的解決流程，是由這些演算法族的組合而解決的。而模板模式，它分來高低層，在高層是演算法的邏輯控制，以及一些公有方法的實現。在子類裡，只需要實現具體的細節。策略，是物件的組合。模板，使用的是繼承。
WordPress搬家方法
因為要更換主題，想把原來的 搬到本地進行測試，由此接觸到wordpress搬家。這其間碰到大量問題，還好有搜尋引擎的幫助。最終把這些問題一一解決，在這裡寫個總結。wordpress搬家包括2部分 wordpress系統程式和mysql資料庫。搬家有網域名稱目錄不變只改變空間 網域名稱目錄改變空間不變...
模板方法模式
有這樣乙個場景 乙個演算法或流程，它的步驟以及步驟之間的順序是固定的，但具體的某一步可能有不同的實現。對於這麼乙個場景，可以建立多個類，各個類實現不同的實現，但是這樣的缺點是 易錯 難改，易錯 應為步驟和順序是固定的，而且在每個類中都要寫一遍，程式設計師怎有心情不好的時候，就有可能把其中某一步給寫錯...
模板方法模式
模板方法模式 定義乙個演算法框架，將裡面的操作步驟推遲到子類中去執行，這樣使得子類不用改變框架，只需改變某些操作步驟方法 ifndef test h define test h include include using namespace std class test virtual test v...