facade模式
當你需要使用乙個很複雜的系統，你作為乙個使用者，當然希望使用起來越簡單越好，最好是乙個概念上的功能只需要呼叫乙個函式介面。這時候向你提供系統的人就要考慮使用facade模式了。通過這種模式改進後，系統提供者把系統的對外使用的複雜度降低了，使用者就可以很簡單的使用系統了。舉例來說，在導航軟體中，路徑規劃功能是乙個比較複雜的呼叫過程：
1，設定起點
2，設定終點
3，設定規劃模式
4，計算路徑
5，計算導航資訊
作為使用者，你需要呼叫5個函式來完成，也就是你需要學習5個函式呼叫，每個函式的引數如何設定，5個函式的返回值的含義等等，這些都需要學習。於是，你就會問：「我只需要呼叫乙個函式，引數為3個（起點，終點，模式），只需要呼叫一次就好了。」並且，這5個函式就是乙個整體，乙個路徑規劃必須包含這5個過程。於是，提供者提供了乙個介面，內部就是呼叫上面5個函式來實現。這就是facade模式。
adapter模式
為了統一介面風格，而現有的系統同樣的功能確實另乙個名字，這時候就可以用把現有的系統封裝成乙個類，這個類暴露出統一的介面風格，而這個介面的內部實現只是簡單的呼叫原來那個功能。其實就是把現有的函式名，使用用使用者希望的函式名再包一層出去。舉例來說，你有乙個shap類，shap類有3個子類，point類，line類和square類。shap類中有個虛函式為display（）。每個子類都會具體實現display（）函式，這個就是多型。對子類顯示功能，都可以通過父類指標呼叫display（）函式來實現。這時候，我們需要新增乙個circle類，很顯然的想法，circle類也從shap中繼承，這樣通過父類指標呼叫display（）也就可以實現顯示功能，和其他3個子類的使用方法一樣。但是問題出來了，隔壁有人已經實現了circle類類似的功能，秉著復用的精神，我們最好直接拿過來用。但是，他們的circle類有另乙個名字，叫xxcircle類，它的顯示函式不叫display（），叫xxdisplay（）。狀況變成，要使用已經實現的xxcircle類，必然無法統一使用父類指標操作，如果修改xxcircle類，對方不見得同意，並且修改總會帶來bug。這時候adapter模式出現了。你還是定義自己的circle類，繼承於shape類，介面函式名也是display（）。這是circle類中包含乙個xxcircle類的物件，而display（）內部函式通過呼叫xxcircle類物件的xxdisplay（）方法來實現。
總結上面2種模式有其相同之處，就是對現有系統的內容不做修改，而是把對外的介面重新定義了下。區別在於facade中新定義的介面通過呼叫現有系統多個函式來實現，它們是1對多的關係；而adapter中新定義的介面和內部原來的介面為1對1的關係。
設計模式 1
oo 基礎 1 抽象 2 封裝 3 多型 4 繼承 oo原則 1 封裝變化 2 多用組合，少用繼承 3 針對介面程式設計，不針對實現程式設計 4 為互動物件之間的松耦合設計而努力 5 類應該對擴充套件開放，對修改關閉 6 依賴抽象，不要依賴具體類 7 只和朋友交談 8 別找我，我會找你 9 類應該只...
設計模式（1）
單例模式 保證為乙個類只生成唯一的例項物件。也就是說在整個程式空間中該類只存在乙個例項物件。include using namespace std class usermanager public static usermanager getinstance private static userm...
設計模式1
讀後感 陸續花了三周時間，閱讀了 大話設計模式 的電子書版本。在此之前也閱讀過其它講解設計模式的書，但是往往過於抽象，舉例複雜，讀起來很是吃力，都堅持不下來 閱讀這本書比較輕鬆。本書的優點 就是淺顯易懂，適合於入門者 本書的缺點 就是有些地方講解並不深入全面 並沒有給出用.net實現時，如何實現更優...