本週課程先大致介紹了設計模式的概念以及產生原因，然後詳細講解了設計模式的幾大原則，接著按照順序介紹了模板方法、策略模式、觀察者模式、裝飾模式、橋模式這幾個設計模式。
課程目標：
• 理解松耦合設計思想
• 掌握物件導向設計原則
• 掌握重構技法改善設計
• 掌握gof核心設計模式
一、程式開發的兩種思維
1.底層思維
• 語言構造
• 編譯轉換
• 記憶體模型
• 執行時機制
2.抽象思維
• 物件導向
• 元件封裝
• 設計模式
• 架構模式
二、物件導向設計原則
1.依賴倒置原則
該原則主要描述兩件事情，一是高層模組不應該依賴於底層模組，二者都應該依賴於抽象；二是抽象不應當依賴於實現細節，實現細節應該依賴於抽象。這兩條內容的核心思想是將變化的東西依賴於穩定的東西，實現將變化隔離的效果，這是設計模式的核心思想。這樣，當需要進行變化時，便可以通過擴充套件對應的子類，通過執行時多型來實現，達到**復用的效果。
2.開放封閉原則
即**應該是對擴充套件開放，對更改封閉；類模組應該是可擴充套件的，但是不可修改。這樣可以保證已完成**在後續開發過程中的復用性，防止在修改或者擴充功能時引入新的bug。
3.單一職責原則
乙個類應該僅有乙個引起它變化的原因，即變化的方向應該隱含著類的責任。
4.liskov替換原則
子類必須能夠替換它的父類，即滿足is-a的關係。
5.介面隔離原則
不應該強迫客戶程式依賴它們不用的介面，即設計類時應當將內部使用的函式使用protected或者private的形式影藏起來，使得介面小且完備。這樣在修改程式時便可以避免對客戶程式進行修改。
6.優先使用組合物件，而不是類繼承
在物件導向程式設計中，類繼承是一種「白箱復用」，而物件組合是一種「黑箱復用」。使用類繼承往往子類與父類間耦合度較高，這容易破壞類的封裝性。
7.封裝變化層
使用封裝來建立物件之間的分界層，讓設計者可以再分界層一次進行修改而不會對另一側產生不良影響。
8.針對介面程式設計，而不是針對實現程式設計
即在程式設計時，變數應當盡量宣告為抽象介面或者抽象類，客戶端只需要知道類的介面，而無需知道其底層實現便可以完成功能。這樣在實現產生變化時可以非常方便的修改，而不影響客戶端程式。
三、模板方法
1.應用情景
在軟體構建過程中，對於某一項任務，它常常有穩定的整體操作結構，但各個自步驟卻有很多改變需求，或者由於固有的原因而無法和任務的整體結構同時實現。在這個情境下，穩定的是該任務的執行框架，變化的是每個子任務的具體實現。
2.解決方案
在父類中將任務的執行框架先實現，並將其中易便的子步驟設定為protected虛函式，在子類進行發生變化時過載該虛函式。這種設計模式極大的降低了客戶端程式的使用該模組的負擔，並且提供了一種反向呼叫結構，是非常常見的設計模式。
其結構如下圖所示：
四、策略模式
1.應用情景
在軟體構建過程中，某些物件使用的演算法可能多種多樣，經常改變，如果將這些演算法都編碼到物件中，將會使得物件變得異常複雜；而且有時候支援不使用的演算法也是乙個效能負擔。
2.解決方案
將多個演算法從**中提取出來，封裝成乙個個的策略類，並提供乙個統一的介面作為父類。在需要使用多種演算法的物件中定義乙個該演算法的父類指標，根據傳進去的子類實現執行時確定計算方法。這樣便可以在不更改物件源**的情況下非常輕鬆的擴充套件策略演算法。如果演算法本身不涉及資料儲存，演算法類也可以使用單例模式設定，降低記憶體消耗。
其結構如下圖所示：
五、觀察者模式
1.應用情景
在軟體構建過程中，我們需要為某些物件建立一種「通知依賴關係」——乙個物件（目標物件）的狀態發生改變，所有的依賴物件（觀察者物件）都將得到通知。如果這樣的依賴關係過於緊密，將使軟體不能很好地抵禦變化。
2.解決方案
在軟體中為定義乙個發出通知的介面，對於需要接受通知的類便可以繼承該介面並實現它。在發出通知的類中放置乙個介面陣列，在客戶端程式中將所有需要接受通知的物件都放置進該陣列中。這樣，便可以實現通過客戶程式靈活的選擇和分配訊息傳送渠道，實現發出通知**的復用。
其結構如下圖所示：
六、裝飾模式
1.應用情景
在某些情況下我們可能會「過度的使用繼承來擴充套件物件的功能」，由於繼承為型別引入的靜態特質，使得這種擴充套件方式缺乏靈活性；並且隨著子類的增多（擴充套件功能的增多），各種子類的組合（擴充套件功能的組合）會導致更多的子類膨脹。即我們需要找到一種方式，實現功能可通過非繼承方式擴充套件，但是介面不發生變化的類。
2.解決方案
先定義乙個抽象基本型別，為該基本型別定義兩種子類，一種是不含有基類指標的子類，實現基本功能；另一種是含有基類指標的子類，實現基於基本功能之上的擴充套件功能。在某些情況下，也會為後一種型別子類抽象出乙個基類作為裝飾基類。這個設計模式實現了在介面上為is-a關係，在實現上為has-a關係的設計，解決了主題類在多個方向上擴充套件功能的問題。
其結構如下圖所示：
七、橋模式
1.應用情景
由於某些型別的固有的實現邏輯，使得它們具有兩個變化的維度，乃至多個維度的變化。這是違反單一職責原則的。
2.解決方法
將基類的介面按照變化維度拆分，再將這些拆分後的介面組合起來，以適應類在不同情況下的變化。
其結構如下圖所示：
博覽網 物件導向高階程式設計（上） 第一周課程筆記
程式語言學習往往分為兩個部分，一是該語言的語法特性，包括關鍵字 強型別還是弱型別 是否支援指標等等 二是該語言的標準庫，包括提供的基本容器 輸入輸出方法等等。物件導向高階程式設計 上 這門課程主要是介紹第一部分的內容。一 課程基本目標 1.以良好的方式編寫c class，包括以下兩種型別 內部無指標...
博覽網 設計模式 第二週課程筆記
本週接著介紹詳細的具體的設計模式，包括工廠方法 抽象工廠模式 原型模式 構建器 門面模式 模式 介面卡和中介者。一 工廠方法 1.應用情景 在軟體系統中，經常面臨著物件建立的工作 由於需求的變化，需要建立的物件的具體型別經常發生變化。2.解決方案 在軟體中，可以通過將new封裝到工廠類的create...
馬哥教育第一周課程感悟
自5月8日開課以來，已經過去近兩周的時間，在這裡對近期的課程體驗做一下簡單的總結 一 主講王曉春老師 課程安排合理，第一天從linux的起源開始給我們娓娓道來，讓我們對所學的知識有了一種親切感，而不是那種高高在上遙不可及的感覺 在課程的不斷進行中，王老師能夠利用自身20多年的理論和實踐的親身經歷深入...