近年來，在物件導向領域中的乙個重要突破就是提出了設計模式的概念。軟體的設計模式是人們在長期的開發實踐中良好經驗的結晶，它提供了乙個簡單、統一的描述方法，使人們可以復用這些軟體設計方法、過程管理經驗。由於設計模式在表達上既經濟又清楚，從而越來越受到重視。
本章將介紹軟體設計模式的概念、組成要素和分類，並介紹了 facade、adapter、abstract factory 等常用設計模式。
在任何設計活動中都存在著某些重複遇到的典型問題，不同開發人員對這些問題設
計出不同的解決方案，隨著設計經驗在實踐者之間日益廣泛地被利用，描述這些共同問題和解決這些問題的方案就形成了所謂的模式。
7.1.1 設計模式的歷史
模式概念是建築師 christopher alexander 提出的，他提出可以把現實中一些已經實
現的較好的建築和房屋的設計經驗作為模式，在以後的設計中直接加以運用。他還定義了一種「模式語言」來描述建築和城市中的成功的架構。
christopher alexander 將模式分為幾個部分：首先是特定的情景（context) , 指模式在何種狀況下發生作用；其二是動機（system of force) , 指問題或預期的目標；其三是解決方案（solution) , 指平衡各動機或解決所闡述問題的乙個構造或配置。他提出模式是表示特定的情景、動機、解決方案三個方面關係的乙個規則，每個模式描述了乙個在某種特定情景下不斷重**生的問題，以及該問題解決方案的核心所在。模式既是乙個事物又是乙個過程，不僅描述該事物本身，而且提出了通過怎樣的過程來產生該事物。設計模式的核心是問題描述和解決方案，問題描述說明模式的最佳使用場合及它將如何解決問題，解決方案是用一組類和物件及其結構和動態協作來描述的。
20世紀80年代中期由 ward cunningham 和 kent beck 將其思想引入到軟體領域。2023年，e. gamma, r. helm, r. johnson和j. vlissides4人合著了 design patterns; elements of object-oriented software, 這是軟體設計模式領域中的一本經典書籍，從此設計模式成為軟體工程領域內的乙個重要研究領域，這四人也因此被稱為gang of four (gof) , 成為設計模式中的大師級人物。
7.1.2 為什麼要使用設計模式
物件導向設計時需要考慮許多因素，例如封裝性、粒度大小、依賴關係、靈活性和可重用性等。如何確定系統中類及類之間的關係？如何保證在系統內部的乙個類始終只有乙個例項被建立？如何動態地將追加的功能增加到乙個物件？哪些是設計時要達到的目標？這些都是軟體設計中不容易掌握的問題。要真正掌握軟體設計，必須研究其他軟體設計大師的設計，這些設計中包含了許多設計模式。軟體模式的應用對軟體開發產生了重大的作用，主要表現在以下幾個方面。
簡化並加快設計
開發人員面對的問題來自不同的層次。在最底層，涉及的是單個類的介面或實現的細節問題；在最高層，涉及的是系統的整體架構的建立問題。設計模式關注的是中間層，在這一層必須保證區域性化的特定的設計性質。設計模式使得軟體開發人員無須從底層做起，開發人員可以重用成功的設計，可節省開發時間，同時有助於提高軟體質量。
方便開發人員之間的通訊
利用設計模式可以更準確地描述問題及問題的解決方案，使解決方案具有一致性。
也有利於開發人員可以在更高層次上思考問題和討論方案。例如，如果所有人都理解factory 設計模式的意思，則開發人員可以用「建議採用 factory 設計模式來解決這個問題」這樣的話來表達。
降低風險
由於設計模式經過很多人的使用，已被證明是有效的解決方法，所以採用設計模式
可以降低失敗的可能性，也有利於在複雜的系統中產生簡潔、精巧的設計。
有助於轉到物件導向技術
新技術要在乙個開發機構中得到應用，一般要經歷兩個階段，即技術獲取階段和技
術遷移階段。技術獲取階段較容易，但在技術遷移階段，由於開發人員對新技術往往會有牴觸或排斥心理，對新技術可能帶來的效果持懷疑態度，同時由於對新技術還是一知半解，所以要在乙個開發機構中進行技術遷移並不是一件容易的事。設計模式一般都是基於物件導向技術而提出的，也可應用於介面定義良好的結構化方法中。另外，設計模式是可重用的設計經驗的總結，已在實際的系統中多次得到成功應用，因此通過對設計模式的研究，能夠深入理解良好設計的最基本的性質，從而有助於說服開發人員採用新技術。
成熟的軟體設計模式具有以下特性。
（1) 巧妙：設計模式是一些優雅的解決方案，是在大量實踐經驗的基礎上提煉出
來的。（2) 通用：設計模式通常不依賴於某個特定的系統型別、程式語言或應用領域，它們是通用的。
（3）得到很好的證明：設計模式在實際系統和物件導向系統中得到廣泛應用，它們
並不僅僅停留在理論上。
（4）簡單：設計模式通常都非常簡單，只涉及很少的一些類。為了構建更多更複雜
解決方案，可以把不同的設計模式與應用**結合或混合使用。
（5） 可重用：設計模式的建檔方式使它們非常易於使用，因而可方便用於任何適宜的系統。
（6) 物件導向：設計模式是用最基本的物件導向機制如類、物件、多型等構造的。許多模式特別強調了菜些物件導向設計擅長的領域，例如，區分介面和實現、降低各部分之間的依賴性、隔離硬體和軟體等。
7.1.3 設計模式的組成元素
模式是乙個高度抽象的概念。設計模式的基本組成元素如下。
模式名模式必須具有乙個有意義的名稱，這樣就可以用乙個詞或短語來指代該模式，以及
它所描述的知識和結構。模式名稱簡潔地描述了模式的本質。模式名可以幫助我們思考，便於我們與其他人交流設計思想及設計結果，找到恰當的模式名也是設計模式編目工作的難點之一。
問題或意圖
陳述問題並描述它的意圖，以及它在特定的情景和動機下要達到的目標，它解釋了
設計問題和問題存在的前因後果，它可能描述了特定的設計問題，如怎樣用物件表示演算法等，也可能描述了導致不靈活設計的類或物件結構。有時候，問題部分會包括使用模式必須滿足的一系列先決條件。通常情況下這些動機和目標是相互矛盾、相互影響的。
情景情景是問題及其解決方案產生時的前提條件。情景告訴我們該模式的適用性，可以
將情景視為應用該模式之前的系統初始配置。
動機它描述相關的動機和約束，它們之間或與期望達到的目標之間的相互作用（或衝突），通常需要對各期望的目標進行優先順序排序。動機闡明了問題的複雜性，定義了在相互衝突時所採取的各種權衡手段。乙個好的模式應盡可能將所有產生影響的動機考慮在內。
解決方案
解決方案是描述一些靜態的關係和動態的規則，用以描述如何得到所需的結果。通
常是給出一組指令來說明如何構造所需的工作製品。該說明可包括圖表、文字，用以標示模式的結構、參與者及其之間的協作，從而表明問題是如何解決的。因為模式就像乙個模板，可應用於多種不同的場合，所以解決方案並不描述乙個特定而具體的設計或實現，而是提供設計問題的抽象描述和怎樣用乙個具有一般意義的元素組合（類或物件組合）來解決這個問題。
示例示例指乙個或多個模式的應用例子，示例說明了模式在怎樣的初始情景下如何發生作用，如何改變情景而導致結果情景的出現。示例帶助該有理解模式的具體使用方法。
結果情景
結果情景指在該模式後系統的狀態或配置，包括模式發生作用後帶來的後果，以及在新的情景下產生的問題、可應用的模式等，它闡述了模式的後續狀態和***，
通常通過對結果情景的描述，使該模式與其他模式聯絡起採（該模式的結果情景成為其他模式的初始情景）。
基本原理
基本原理指對該模式中的解決步驟或採用的規則的解樣、證明，解釋該模式如何、為何能解決當前問題，它採用的方法為何能得到與期望相一致的結果。
相關模式
該模式與其他模式的關係，包括靜態的和動態的。例如，該模式的前導模式（前導
模式應用後產生的結果情景與該模式的初始情景一致）、後續模式（該模式應用後產生的結果情景與後續模式的初始情景一致）、替代模式（使用該模式的替代模式產生同樣的效果）等。
已知應用
闡述該模式在已有應用系統中的實際應用情況，有助於驗證該模式的有效性。盡第
我們描述設計決策時，並不總提到模式效果，但它們對於評價設計選擇和理解使用模式的代價及好處具有重要意義。模式效果大多關注對時間和空間的衡量，它們也表述了語言和實現問題。因為復用是物件導向設計的要素之一，所以模式效果包括它對系統的靈活性、擴充性或可移植性的影響，顯式地列出這些效果對理解和評價這些模式很有幫助。
通常好的模式前面都有乙個摘要，提供簡短的總結和概述，為模式描繪出乙個清晰
的圖畫，提供有關該模式能夠解決問題的快速資訊。有時這種描述稱為模式縮略概要，或乙個縮圖。模式應該說明它的目標讀者，以及對讀者有哪些知識要求。
7.1.4 設計模式的分類
軟體模式主要可分為設計模式、分析模式、組織和過程模式等，每一類又可細分為若於個子類。在此著重介紹設計模式，目前它的使用最為廣泛。設計模式主要用於得到簡潔靈活的系統設計，gof 的書中共有23個設計模式，這些模式可以按兩個準則來分類：一是按設計模式的目的劃分，可分為建立型、結構型和行為型三種模式；二是按設計模式的範圍劃分，即根據設計模式是作用於類還是作用於物件來劃分，可以把設計模式分為類設計模式和物件設計模式。
建立型模式
該型別模式是對物件例項化過程的抽象，它通過採用抽象類所定義的介面，封裝了系統中物件如何建立、組合等資訊。
結構型模式
該模式主要用於如何紐合已有的類和物件以獲得更大的結構，一般借鑑封裝、**、繼承等概念將乙個或多個類或物件進行組合、封裝，以提供統一的外部檢視或新的功能。
行為型模式
該類模式主要用於物件之間的職責及其提供的服務的分配，它不僅描述物件或類的
模式，還描述它們之間的迪信模式，特別是描述一組對等的物件怎樣相互協作以完成其中任一物件都無法單獨完成的任務。
系統架構設計師學習之路（17）
4.1.1 軟體開發生命週期 軟體開發周期是指軟體產品從形成概念 構思 開始，經過定義 開發 使用和維護，直到最後被廢棄 不再使用 為止的全過程。1.軟體定義時期 1 問題定義 2 可行性研究 3 需求分析 2.軟體開發時期 概要設計 詳細設計 編碼3.軟體執行及維護 軟體執行 軟體維護 4.1.2...
系統架構設計師學習之路（11）
2.4.3 多 系統的組成 1.多 硬體 2.多 軟體 多 軟體系統按功能分為系統軟體 應用軟體。系統軟體是多 系統的核心，不僅具有綜合使用各種 靈活排程多 資料進行 的傳輸和處理的能力，而且要控制各種 硬體裝置協調地工作。多 系統軟體主要包括多 作業系統 素材製作軟體及多 函式庫 多 創作工具與開...
系統架構設計師學習之路（30）
6.2.5 狀態圖和活 1.狀態圖 uml中的狀態圖主要用於描述乙個物件在其生存期間的動態行為，表現乙個物件所經歷的狀態序列，引起狀態轉移的事件，以及因狀態轉移而伴隨的動作。狀態圖是uml中對系統的動態行為建模的五個圖之一。狀態圖在檢查 除錯和描述類的動態行為時非常有用。一般可以用狀態機對乙個物件的...