《大話設計模式》閱讀筆記 我的版

面向對象：易維護 易擴展 能複用 工廠模式： 什麼是工廠：一個用於創造實例的類 應對有限個不會多變的算法需求 基本套路： 1 建立一個抽象基類 2 根據不一樣狀況設計不一樣子類繼承於抽象基類//繼承
3 建立一個工廠類來依據不一樣狀況生產不一樣算法子類的對象//多態
4 有新需求則須要新建子類並在工廠中修改代碼實現生產此類對象的分支 5 在客戶端低耦合地使用工廠 //計算器
* 工廠返回算法子類 策略模式： 定義：它定義了算法家族，分別封裝起來，讓它們之間能夠相互替換，此模式讓算法的變化，不會影響到使用算法的客戶 策略模式就是用來封裝算法的，但在實踐中，咱們發現能夠用它來封裝幾乎任何類型的規則， 只要在分析過程當中聽到須要在不用時間應用不一樣的業務規則，就能夠考慮使用策略模式處理這種變化的可能性 基本套路： 1 找到全部狀況下各算法共同點---建立抽象基類 2 基於不一樣狀況設計不一樣子類繼承於抽象基類 一個算法至關於一種策略 3 建立上下文（Context）類 維護一個對策略對象的引用 4 對於新的需求則一樣建立新的策略 5 客戶端低耦合使用上下文類 //收銀系統
* 上下文中實現抽象基類的目標方法 在裏面調用具體算法的方法 單一職責原則： 準確解釋：就一個類而言，應該僅有一個引發它變化的緣由 軟件設計真正要作的許多內容，就是發現職責並把那些職責相互分離 若是可以想到多於一個的動機去改變一個類，那麼這個類就具備多於一個的職責 遊戲設計中 界面的變化是和遊戲自己沒有關係的，界面是容易變化的，遊戲邏輯是不太容易變化的，將它們分離開有利於界面的改動 基本套路： 分析問題，在構造類的時候想清楚使其改變的動機（通常不一樣場景就是不一樣職責 構建不一樣的類使職責單一化） 開放-封閉原則： 解釋：軟件實體（類、模塊、函數等等）應該能夠擴展，可是不能夠修改 兩大特徵：對於擴展是開放的，對於更改是封閉的 此原則確保面對需求的改變卻能夠保持相對穩定，從而使得系統能夠在第一個版本之後不斷退出新的版本 對程序的改動是經過增長新代碼進行的，而不是更改現有的代碼 依賴倒轉原則： 抽象不該該依賴細節，斜街應該依賴於抽象 要針對接口編程，不要對實現編程 里氏代換原則：子類型一定可以替換掉它們的父類型 只有當子類能夠替換掉父類，軟件單位的功能不受到影響時，父類才能真正被複用，而子類也可以在父類的基礎上增長新的行爲 高層模塊不該該依賴底層模塊，二者都應該依賴抽象 裝飾模式： 動態地給一個對象添加一些額外的職責，就增長功能來講，裝飾模式比生成子類更爲靈活 裝飾模式是爲已有功能動態添加更多功能的一種方式 基本套路： 1 建立組件類（父類） 2 建立裝飾類繼承於組件類，含有對組件類的一個實例，用於在其基礎上進行裝飾 3 建立衆多具體的裝飾類繼承於裝飾類，它們之間的實例能夠互相裝飾 4 依據裝飾過程的不一樣獲得不一樣的對象 代理模式： 對其餘對象提供一種代理以控制對這個對象的訪問 基本套路： 1 建立抽象類（基類）--公共接口 2 建立真實類繼承於基類，含有具體的功能實現 3 建立代理類繼承於基類，含有真實類的實例的引用 4 在代理中實現具體功能，能夠在這裏實現對真實類的封裝，使其不可見 工廠方法模式： 定義一個用於建立對象的接口，讓子類決定實例化哪個類。工廠方法使一個類的實例化延遲到了其子類 區別於簡單工廠模式：簡單工廠模式的最大優勢在於工廠類中包含了必要的邏輯判斷，根據客戶端的選擇條件動態實例化相關的類，對客戶端來講，去除了與具體產品的依賴 工廠方法模式把簡單工廠的內部邏輯判斷移到了客戶端代碼來進行，想要加功能原本是改工廠類，而如今是修改客戶端 基本套路： 1 定義工廠方法所建立的對象的接口 2 定義抽象工廠，含有返回要被建立實例的方法 3 對於特定功能建立具體實用類繼承對象接口 4 建立具體工廠類繼承抽象工廠，針對不一樣實用類建立不一樣的工廠來生產相應的對象 5 客戶端直接採用具體實用類的工廠來建立不一樣的對象 原型模式： 從一個對象再建立另一個可定製的對象，並且不須要知道任何建立的細節 Clone對象：通常在初始化的信息不發生改變的狀況下，克隆是最好的方法， 這既隱藏了對象建立的細節，又對性能是大大的提升 淺複製：被複制對象的全部變量都含有與原來的對象相同的值，而全部的對其餘對象的引用都扔指向原來的對象 深複製：把引用對象的變量指向複製過的新對象，二不是原有的被引用的對象 將原型實現可克隆接口，實現具體的克隆方法，客戶端調用 模板方法模式： 定義一個操做中的算法的骨架，而將一些步驟延遲到子類中 模板方法使得子類能夠不改變一個算法的結構便可重定義該算法的某些特定步驟 優點：模板方法模式是經過把不變行爲搬移到超類，去除子類中的重複代碼 基本套路： 1 定義抽象頂級類--抽象模板，定義並實現了一個模板方法（具體的方法），它給出一個頂級邏輯的骨架，邏輯的組成步驟在相應的抽象操做中 abstract class AbstractClass{ public abstract void PrimitiveOperation1(); public abstract void PrimitiveOperation2(); public void TemplateMethod(){//具體的方法
        PrimitiveOperation1();//邏輯
 PrimitiveOperation2(); } } 2 實現具體任務類繼承於頂級類，實現父類定義的抽象方法 3 客戶端採用多態來調用具體的方法 迪米特法則： 最少知識原則 若是兩個類沒必要彼此直接通訊，那麼這兩個類就不該當發生直接的相互做用。若是其中一個類須要調用另外一個類的某一個方法的話，能夠經過第三者轉發這個調用 在類的結構設計上，每個類都應當儘可能下降成員的訪問權限： 白話解釋：一個類包裝好本身的private狀態，不須要讓別的類知道的字段或行爲就不要公開 外觀模式： 爲子系統中的一組接口提供一個一致的界面，此模式定義了一個高層接口，這個接口使得這一子系統更加容易使用 我的理解：對複雜的系統進行封裝，獲得簡單可用的接口，客戶端僅須要瞭解外觀接口便可 基本套路： 1 單獨實現下面的子系統--各類功能類 2 實現外觀類，來對下面子系統的功能進行整合封裝 3 客戶端無需瞭解下面的子系統，直接針對外觀的接口進行調用，就能夠充分的使用子系統 建造者模式： 又叫：生成器模式 建造者模式能夠將一個產品的內部表象與產品的生成過程分割開來，從而可使一個建造過程生成具備不一樣的內部表象的產品對象 指揮者：用它來控制建造過程，也用它來隔離用戶與建造過程的關聯 基本套路： 1 建立建造者，爲建立一個產品對象的各個部件指定的抽象接口，含有共有的抽象方法（保證新添加的類中不會由於疏忽丟失功能） 2 建立具體產品的的建造者，繼承於建造者，實現具體的抽象方法 3 建立一個指揮者，構建一個使用建造者接口的對象，內部含有建造者的一個引用，建立指揮者實例時傳入指定建立者（基於多態） 4 客戶端經過指揮者來建立不一樣的產品 何時用： 主要用於建立一些複雜的對象，這些對象內部構建間的建造順序一般是穩定的，但對象內部的構建一般面臨着複雜的變化 觀察者模式： 又叫：發佈-訂閱模式 定義了一種一對多的依賴關係，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態發生變化時，會通知全部觀察者對象，使它們可以自動更新本身 基本套路： 1 定義抽象通知者--抽象類/接口 把全部對觀察者對象的引用保存在一個彙集裏 提供接口來增長或刪除觀察者對象 2 定義抽象化觀察者，在獲得主題的通知時更新本身--更新接口 Update方法 3 定義具體主題或者通知者，將有關狀態存入具體觀察者對象，主題內部狀態發生改變時，給全部登記過的觀察者發出通知--繼承於抽象通知者 4 定義具體觀察者，實現更新接口來使自身的狀態與主題的狀態相協調，保存一個指向具體通知者對象的引用 做用：解除耦合，讓耦合的雙方都依賴與抽象，而不是依賴於具體 委託（delegate）： 是一種引用方法的類型，一旦爲委託分配了方法，委託將與該方法具備徹底相同的行爲 委託方法的使用能夠像其餘任何方法同樣，具備參數和返回值 委託能夠看做是對函數的抽象，是函數的‘類’，委託的實例將表明一個具體的函數 一個委託能夠搭載多個方法，全部方法被依次喚起 可使得委託對象所搭載的方法並不須要屬於同一個類 C#: delegate void EventHandler();//聲明瞭一個特殊的類 函數的類
用： public event EventHandler Update;//聲明瞭一個事件委託變量叫 Update
huhansan.Update += new EventHandler(tongshi1.CloseStockMarket);//將‘tongshi1.CloseStockMarket’這個方法委託給‘huhansan.Update’這個方法
要求：委託對象所搭載的全部方法必須具備相同的圓形：相同的參數列表，相同的返回值類型 抽象工廠模式： 提供一個建立一系列相關或相互依賴對象的接口，而無需指定它們具體的類 基本套路： 1 定義抽象工廠接口，包含全部的產品建立的抽象方法 2 定義具體工廠類，繼承於抽象工廠接口，實現具體生產不一樣類的對象的方法 3 定義抽象產品接口，含有此類產品的相關任務 4 定義具體的產品類，繼承於抽象產品接口，對抽象產品的具體實現 5 爲建立不一樣的產品對象，客戶端應使用不一樣的具體工廠 ps：反射代替switch 添加配置文件避開修改代碼 狀態模式： 當一個對象的內在狀態改變時容許改變其行爲，這個對象看起來像是改變了其類 適用於： 當控制一個對象狀態轉換的條件表達式過於複雜時，把狀態的判斷邏輯轉移到表示不一樣狀態的一系列類當中，能夠把複雜的判斷邏輯簡化 基本套路： 1 定義一個抽象狀態類--一個接口/抽象類，來封裝與上下文的一個特定狀態相關的行爲 2 定義具體狀態類，每一個子類實現一個與上下文的狀態相關的行爲 3 定義上下文類，來維護一個具體狀態子類的實例，這個實例定義當前狀態 目的：消除龐大的條件分支語句 適配器模式： 將一個類的接口轉換成客戶但願的另一個接口 適配器模式使得本來因爲接口不兼容而不能一塊兒工做的那些類能夠一塊兒工做 解決問題：須要的東西就在眼前，但卻不能使用，而短期又沒法改造它，這是就要想辦法適配它 基本套路： 1 特殊的類 2 定義目標類，客戶所期待的接口--具體的或抽象的類或接口 3 定義適配器繼承於目標類，並在其中含有特殊類對象的實例的引用，經過方法對其進行封裝（相似於代理） 備忘錄模式： 在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態，這樣之後就可將該對象恢復到原先保存的狀態 基本套路： 1 定義屬性會變的類，並在其中定義保存狀態及恢復狀態的方法 2 定義存儲箱類，來針對具體屬性進行存儲 3 定義管理者，含有對存儲箱對象的應引用，並定義get/set方法獲取或設置存儲箱的狀態 4 客戶端使用管理者和來恢復存儲的狀態 組合模式： 將對象組合成樹形結構以表示「部分-總體」的層次結構，組合模式使得用戶對單個對象和組合對象的使用具備一致性 基本套路： 1 定義基本模型--抽象類，在其中定義都會用到的方法（抽象） 2 定義具體的事物類，繼承於基本類，來實現具體的方法（枝節點/葉子節點） 3 客戶端相同對待基本對象和組合對象 透明方式： 抽象類中定義全部的規範方法 在具體實現類中如沒有此功能，則爲空，什麼也不作或給出提示 好處：全部具體類具有徹底一致的行爲接口 安全方式： 抽象接口中對於不一樣具體類之間的差別部分不作同一規定，在具體類中本身來定義所需方法 好處：安全 可是因爲不具有徹底一致的接口，客戶端的調用須要作相應的判斷 何時用： 需求中是體現部分與總體層次的結構時，以及但願用戶能夠忽略組合對象與單個對象的不一樣，同一地使用組合結構中全部對象時 迭代器模式： 提供一種方法順序訪問一個聚合對象中各個元素，而又不暴露該對象的內部表示 實現Iterable接口 單例模式： 保證一個類僅有一個實例，並提供一個訪問它的全局訪問點 讓類自身負責保存它的惟一實例 將類的構造器設置爲private，外部就不能夠採用new來創造它的實例 是否創造此類的實例由它本身說了算 基本套路： 1 將類的構造器設置爲private，內部定義靜態成員指向本類的實例的引用 2 類內添加public的實例化方法，來進行本身管理 雙重鎖定： if(instance == null){/////
    lock(syncRoot){ if(instance == null){////
            instance = new Singleton(); } } } 靜態初始化：在類加載時將本身實例化 --餓漢式單例類 在第一次被引用時，纔會將本身實例化 --懶漢式單例類 區別：餓漢式在類一加載就實例化，要提早佔用系統資源 線程安全 懶漢式面臨線程安全問題，須要作雙重鎖定這樣的處理來保證安全 橋接模式： 將抽象部分與它的實現部分分離，使它們均可以獨立得變化 通俗理解：實現系統可能有多角度分類，每一種分類都有可能變化，那麼就把這種多角度分離出來讓它們獨立變化，減小它們之間的耦合 合成/聚合複用原則：儘可能使用合成/集聚合，儘可能不要使用類繼承 合成關係：翅膀--->大雁      聚合關係：大雁--->雁羣 各種軟件--->軟件            軟件--->手機品牌 命令模式： 將一個請求封裝爲一個對象，從而使你可用不一樣的請求對客戶進行參數化，對請求排隊或記錄請求日誌，以及支持可撤銷的操做 基本套路： 1 定義命令類，含有接收命令對象的引用，以及抽象的執行方法 2 定義具體命令類，實現執行方法，方式爲調用接收者相應的操做 3 定義調用者類，要求該命令執行這個請求 4 定義接收者類，執行與請求相關的操做 職責鏈模式： 使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合關係。將這個對象連成一條鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理它爲止 基本套路： 1 定義處理請求的接口--抽象類，含有設置繼任者的方法，以及處理請求的抽象方法 2 定義具體處理者類繼承於抽象類，實現具體職責--本身能處理則處理，不能交給後繼者 中介者模式： 又叫調停者模式 用一箇中介對象來封裝一系列的對象交互。中介者使各對象不須要顯示地相互引用，從而使其耦合鬆散，並且能夠獨立地改變它們之間的交互 基本套路： 1 定義中介者類--抽象類，定義用於協調具體實例間問題的抽象方法 2 定義具體中介者類，繼承於抽象類，含有全部須要維護關係的類的實例，並實現協調方法 3 定義由各種泛化來的抽象類，含有中介者類的實例引用，並在構造器中傳入中介者 4 定義具體的各種，完成本身的功能方法 享元模式： 運用共享技術有效地支持大量細粒度的對象 目的：共享對象，節約資源 基本套路： 1 發現須要大量建立的各類實例間的相同與不一樣之處 2 相同的部分爲內部狀態，寫入一個類中 3 不一樣的部分爲外部狀態，在外部定義新的類，並在2中的類中使用指向其實例的引用 4 經過hashmap存儲，設置key，若是key相同其已經實例過此類的實例則直接返回，並在客戶端修改外部狀態 解釋器模式： 給定一個語言，定義它的文法的一種表示，並定義一個解析器，這個解析器使用該表示來解釋語言中的句子 基本套路： 1 定義抽象解釋類，這個接口爲抽象語法樹中全部的節點所共享 2 定義具體文法解釋類，繼承於抽象類，實現不一樣文法解釋的方法 3 客戶端採用case分支建立不一樣文法解釋實例 訪問者模式： 表示一個做用於某對象結構中的各元素的操做。它使你能夠在不改變各元素的類的前提下定義做用於這些元素的新操做 基本套路： 1 定義抽象訪問者，根據固定的數據結構定義抽象visit操做（男人/女人） 2 定義具體的訪問者類，繼承於抽象訪問者，實現由每一個Visitor聲明的操做（不一樣狀態：成功/失敗  結婚/戀愛 ...） 3 定義一個抽象元素類，定義抽象Accept操做，以一個訪問者爲參數 4 定義具體的元素類，繼承與抽象元素類，實現Accept方法（利用雙分派技術，實現處理與技術結構的分離） 5 定義對象結構類，實現對全部元素的管理，提供一個高層的接口以容許訪問者訪問它的元素 使用狀況少

 

---

 

本節完...