引言：什麼是設計模式

1. 一般而言，一個模式有四個要素：

   1. 模式名稱（pattern name）：助記符，用一兩個詞來描述模式的問題、解決方案和效果。
   2. 問題（problem）：描述了應該在何時使用模式。
   3. 解決方案（soluntion）：描述了設計的組成成分，它們之間的相互關係以及各自的職責和協作方式。
   4. 效果（consequences）：描述了模式應用的效果及使用模式應權衡的問題。

   出發點的不同會產生對什麼是模式和什麼不是模式的理解不同。

2. 描述設計模式：模式名和分類、意圖、別名、動機、適用性、結構、參與者、協作、效果、實現、程式碼示例、已知應用、相關模式

3. 模式分類：根據兩條準則對模式分類
   
   1. 目的準則：模式是用來完成什麼工作的。
      
      1. 建立型（Creational）：與物件的建立有關。
      2. 結構型（Structural）：處理類和物件的組合。
      3. 行為型（Behavioral）：對類或物件增氧互動和增氧分配職責進行描述。
   2. 範圍準則：模式主要是用於類還是用於物件。
      
      1. 類模式：處理類和子類之間的關係，這些關係通過繼承建立，是靜態的，在編譯時刻就確定了。
      2. 物件模式：處理物件間的關係，這些關係在執行時刻是可以變化的，更具動態性。
   3. 小結：建立型類模式將物件的布馮建立工作延遲到子類，而建立型物件模式則將它延遲到另一個物件中；結構性類模式使用繼承機制來組合類，而結構性物件模式則描述了物件的組裝方式；行為型類模式使用繼承描述演算法課控制流，而行為型物件模式則描述一組物件怎樣協作完成單個物件所無法完成的任務。存在著許多組織設計模式的方法。從多維的角度去思考模式有助於對它們的功能、差異和應用場合的更深入理解。

4. 設計模式怎樣解決設計問題

   1. 尋找合適的物件：物件導向程式由物件組成，物件包括資料和對資料進行操作的過程，過程通常稱為方法或操作。物件在收到客戶的請求（或訊息）後，執行相應的操作。
      物件導向最困難的部分是將系統分解為物件集合。要考慮到許多因素，諸如：封裝、粒度、依賴關係、靈活性、效能、演化、複用等。它們都影響著系統的分解，並且通常還是相互衝突的。
      設計的許多物件來源於現實世界的分析模型。
      設計模式幫你確定並不明顯的抽象和描述這些抽象的物件。
   2. 決定物件的粒度：物件在大小和數目上變化極大。它們能表示下自硬體或上自整個應用程式的任何事物。
   3. 指定物件介面：物件宣告的每一個操作指定操作名、作為引數的物件和返回值，這就是操作的型構。物件操作所定義的所有操作型構的集合被稱為該物件的介面。其描述了該物件所能接受的全部請求集合，任何匹配物件介面中型構的請求都可以傳送給該物件。
      型別是用來標識特定介面的一個名字。一個物件可以有許多型別，並且不同的物件可以共享同一個型別。
      物件只有通過它們的介面才能與外部交流。傳送給物件的請求和它的相應操作在執行時刻的連結就稱為動態繫結（傳送的請求直到執行時刻才受你的具體的實現的約束，即允許在執行時刻彼此替換有相同介面的物件，這種可替代性就稱為多型）。
      設計模式通過確定介面的主要組成成分及經介面傳送的資料型別，來幫助你定義介面。
      設計模式也指定了介面間的關係。
   4. 描述物件的實現：物件的實現由它的類決定的，類指定了物件的內部資料和表示，夜定義了物件所能完成的操作。抽象類的主要目的是為它的子類定義公共介面。
      
      1. 類繼承與介面繼承的比較
         一個物件的類定義了物件是怎樣實現的，同時也定義了物件昂內部狀態和操作的實現。但是物件的型別只與它的介面有關，介面即物件能響應的請求的集合。一個物件可以有多個型別，不同類的物件可以有相同型別。
         類繼承根據一個物件的實現定義了另一個物件的實現。
         介面繼承描述了一個物件什麼時候能被用來替代另一個物件。
      2. 對介面程式設計，而不是對實現程式設計：不將變數宣告為某個特定的具體類的例項物件，而是讓它遵從抽象類所定義的介面。備註：建立型模式確保你的系統是採用針對介面的方式書寫的，而不是針對實現而書寫的。
   5. 運用複用機制
      
      1. 繼承和組合的比較——優先使用物件組合而不是類繼承
         類繼承是在編譯時刻靜態定義的，且可直接使用，但有些缺點：①無法在執行時刻改變從父類繼承的實現；②父類通常至少定義了部分子類的具體表示，所以繼承通常被認為“破壞了封裝性”。
         物件組合是通過獲得對其他物件的引用而在執行時刻動態定義的。組合要求物件遵守彼此介面約定，進而要求更仔細地定義介面。因為物件只能通過介面訪問，所以我們並不破壞封裝性；只要型別一致，執行時刻還可以用一個物件來代替另一個物件；因為物件的實現是基於介面系的，所以實現上存在較小的依賴關係；優先使用物件組合有助於保持每個類被封裝，並被幾種在單個任務上。
      2. 委託：是一種組合方法，它使組合與繼承同樣的複用能力。
         委託的主要優點在於它便於執行時刻組合物件操作以及改變這些操作的組合方式。
         不足：動態的、高度引數化的軟體比靜態軟體更難於理解。
         委託最適用於符合特定程式的情形，即標準模式的情形。
         委託時物件組合的特例。它告訴物件組合作為一個程式碼複用機制可以替代繼承。
      3. 引數化型別：類屬或模板（Templates）
         允許你在定義一個型別時並不指定該型別所用到的其他所有型別。未經指定的型別在使用時以引數形式提供。
      4. 區別
         
         1. 物件組合技術允許在執行時刻改變被組合的行為，但是它存在間接性、比較低效。
         2. 繼承允許提供操作的預設表現，並通過子類重定義這些操作。
         3. 引數化型別允許改變類所用到的型別。
         4. 繼承和引數化型別都不能在執行時刻改變。
   6. 關聯執行時刻和編譯時刻的結構
      
      1. 程式碼結構在編譯時刻就被確定，由繼承關係固定的類組成。
      2. 程式的執行時刻結構是由快速變化的通訊物件網路組成。
      3. 兩個結構彼此獨立
      4. 一個物件包含另一個物件或者是另一個物件的一部分，稱為聚合，意味著聚合物件和其所有者有相同的生命週期。
      5. 相識意味著一個物件僅僅知道另一個物件，它們可能請求彼此的操作，但是它們不為對方負責。

   7. 設計應支援變化
      導致重新設計的原因

      1. 通過顯示地制定一個類來建立物件
      2. 對特殊操作依賴
      3. 對硬體和軟體平臺依賴
      4. 對物件表示或實現依賴
      5. 演算法依賴
      6. 緊耦合
      7. 通過生成子類來擴充功能
      8. 不能方便地對類進行修改

      設計模式通過減少依賴來提高內部複用性。
      框架是構成一類特定軟體可服用設計的一組相互協作的類，規定了你的應用的體系結構。
      框架與設計模式的不同：

      1. 設計模式比框架更加抽象。
      2. 設計模式是比框架更小的體系結構元素。
      3. 框架比設計模式更加特立化。
5. 怎樣選擇設計模式
   
   • 考慮設計模式是怎樣解決設計問題的
   • 瀏覽模式的意圖部分
   • 研究模式怎樣互相關聯
   • 研究目的相似的模式
   • 檢查重新設計的原因。
   • 考慮設計中哪些是可變的
6. 怎樣使用設計模式
   
   1. 大致瀏覽一遍模式。
   2. 回頭研究結構部分、參與者部分和協作部分
   3. 看程式碼例項部分，看看這個模式程式碼形式的具體例子
   4. 選擇模式參與者的名字，使它們在應用上下文中有意義。
   5. 定義類
   6. 定義模式中專用於應用的操作名稱
   7. 實現執行模式中責任和協作的操作。

備註

• 設計模式不能夠隨意使用。
• 通常通過引入額外的間接層次獲得靈活性和可變性的同時，你也使設計變得更加複雜或犧牲了一定的效能。
• 一個設計模式只有當它提供的靈活性是真正需要的時候，才有必要使用。
• 衡量一個設計模式的得失時，它的效果部分是最能提供幫助的。