中南大學(xué)軟件體系結(jié)構(gòu)重點

1、-作者xxxx-日期xxxx中南大學(xué)軟件體系結(jié)構(gòu)重點【精品文檔】第一章 軟件體系結(jié)構(gòu)概述（5分）一、 軟件體系結(jié)構(gòu)的定義l 國內(nèi)普遍接受的定義：軟件體系結(jié)構(gòu)包括構(gòu)件、連接件和約束，它是可預(yù)制和可重構(gòu)的軟件框架結(jié)構(gòu)。l 軟件體系結(jié)構(gòu) = 構(gòu)件 + 連接件 + 約束二、 軟件體系結(jié)構(gòu)的優(yōu)勢l 容易理解l 重用l 控制成本l 可分析性第二章 軟件體系結(jié)構(gòu)風(fēng)格（10分）一、 軟件體系結(jié)構(gòu)風(fēng)格定義l 軟件體系結(jié)構(gòu)風(fēng)格是描述某一特定應(yīng)用領(lǐng)域中系統(tǒng)組織方式的慣用模式。An architectural style defines a family of systems in terms of a patter

2、n of structural organization.l 體系結(jié)構(gòu)風(fēng)格定義了一個系統(tǒng)家族，即一個體系結(jié)構(gòu)定義一個詞匯表和一組約束。詞匯表中包含一些構(gòu)件和連接件類型，而這組約束指出系統(tǒng)是如何將這些構(gòu)件和連接件組合起來的。An architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined.二、 常見的體系結(jié)構(gòu)風(fēng)格l 管道和過濾器 每個構(gòu)件都有一組輸入和輸出，構(gòu)件讀輸入的數(shù)據(jù)流，經(jīng)過內(nèi)部處理，然后產(chǎn)生輸

3、出數(shù)據(jù)流。 過濾器風(fēng)格的連接件就像是數(shù)據(jù)流傳輸?shù)墓艿?，將一個過濾器的輸出傳到另一個過濾器的輸入。l 數(shù)據(jù)抽象和面向?qū)ο蠼M織 數(shù)據(jù)的表示方法和它們的相應(yīng)操作被封裝在一個抽象數(shù)據(jù)類型或?qū)ο笾小?這種風(fēng)格的構(gòu)件是對象或者說是抽象數(shù)據(jù)類型的實例。 對象通過函數(shù)和過程的調(diào)用來進行交互。l 基于事件的隱式調(diào)用 構(gòu)件不直接調(diào)用一個過程，而是觸發(fā)或廣播一個或多個事件。 事件的觸發(fā)者并不知道哪些構(gòu)件會被這些事件影響。l 分層系統(tǒng) 組織成一個層次結(jié)構(gòu)。 每一層都為上一層提供了相應(yīng)的服務(wù)，并且接受下一層提供的服務(wù)。l 倉庫系統(tǒng) 構(gòu)件：中心數(shù)據(jù)結(jié)構(gòu)（倉庫）和一些獨立構(gòu)件的集合。 倉庫和在系統(tǒng)中很重要的外部構(gòu)件之間的相

4、互作用。l 過程控制環(huán)路 源自于控制理論中的模型框架，將事務(wù)處理看成輸入、加工、輸出、反饋、再輸入的一個持續(xù)的過程模型。 通過持續(xù)性的加工處理過程將輸入數(shù)據(jù)轉(zhuǎn)換成既定屬性的“產(chǎn)品”。l C2風(fēng)格通過連接件綁定在一起的按照一組規(guī)則運作的并行構(gòu)件網(wǎng)絡(luò)。l C/S風(fēng)格 基于資源不對等，且為實現(xiàn)共享而提出來的。 有三個主要組成部分：數(shù)據(jù)庫服務(wù)器、客戶應(yīng)用程序和網(wǎng)絡(luò)。 優(yōu)點： 具有強大的數(shù)據(jù)操作和事務(wù)處理能力，模型思想簡單，易于人們理解和接受。 對于硬件和軟件的變化顯示出極大的適應(yīng)性和靈活性，而且易于對系統(tǒng)進行擴充和縮小。 將大的應(yīng)用處理任務(wù)分布到許多通過網(wǎng)絡(luò)連接的低成本計算機上，以節(jié)約大量費用。 缺點

5、： 開發(fā)成本較高。 客戶端程序設(shè)計復(fù)雜。 信息內(nèi)容和形式單一。 用戶界面風(fēng)格不一，使用繁雜，不利于推廣使用。 軟件移植困難。 軟件維護和升級困難。 新技術(shù)不能輕易應(yīng)用。l 三層C/S風(fēng)格 優(yōu)點： 能提高系統(tǒng)和軟件的可維護性和可擴展性。 具有良好的可升級性和開放性。 可以并行開發(fā)。 有效地隔離開表示層與數(shù)據(jù)層，為嚴格的安全管理奠定了堅實的基礎(chǔ)。 缺點： 各層間的通信效率不高。 設(shè)計時必須慎重考慮三層間的通信方法、通信頻率及數(shù)據(jù)量。l B/S風(fēng)格（瀏覽器/Web服務(wù)器/數(shù)據(jù)庫服務(wù)器） 優(yōu)點： 基于B/S體系結(jié)構(gòu)的軟件，系統(tǒng)安裝、修改和維護全在服務(wù)器端解決。用戶在使用系統(tǒng)時，僅僅需要一個瀏覽器就可運

6、行全部的模塊，真正達到了“零客戶端”的功能，很容易在運行時自動升級。 提供了異種機、異種網(wǎng)、異種應(yīng)用服務(wù)器的聯(lián)機、聯(lián)網(wǎng)、統(tǒng)一服務(wù)的最現(xiàn)實的開放性基礎(chǔ)。 缺點： 缺乏對動態(tài)頁面的支持能力，沒有集成有效的數(shù)據(jù)庫處理功能。 系統(tǒng)擴展能力差，安全性難以控制。 數(shù)據(jù)查詢等響應(yīng)速度上，要遠遠低于C/S體系結(jié)構(gòu)。 數(shù)據(jù)提交一般以頁面為單位，數(shù)據(jù)的動態(tài)交互性不強，不利于在線事務(wù)處理(OLTP)應(yīng)用。第三章 軟件需求與架構(gòu)（15分）一、 軟件需求的概念需求是指明必須實現(xiàn)什么的規(guī)格說明。它描述了系統(tǒng)的行為、特性或?qū)傩?，是在開發(fā)過程中對系統(tǒng)的約束。二、 軟件需求的流程三、 軟件需求的分類l 按層分： 業(yè)務(wù)需求：反映

7、組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求，通常問題定義本身就是業(yè)務(wù)需求。領(lǐng)域?qū)＜?用戶需求：描述用戶使用產(chǎn)品必須要完成什么任務(wù)，怎么完成的需求。用戶 系統(tǒng)需求：從系統(tǒng)的角度來說明軟件的需求。開發(fā)人員l 按類分： 功能需求：系統(tǒng)必須完成的那些事，即為了向它的用戶提供有用的功能，產(chǎn)品必須執(zhí)行的動作。 非功能需求：產(chǎn)品必須具備的屬性或品質(zhì)，如正確性、可靠性、性能、容錯性和可擴展性等。 設(shè)計約束：對解決方案的一些約束說明。四、 軟件需求面臨的主要困難l 知識技能問題l 態(tài)度問題l 合作關(guān)系l 用戶說不清楚需求l 雙方誤解需求l 開發(fā)人員寫不好需求文檔l 用戶經(jīng)常變更需求五、 需求工程l 定義：把所有

8、與需求直接相關(guān)的活動通稱為需求工程。l 需求工程創(chuàng)建的第一份文檔是需求陳述，用于在項目開發(fā)之初理解客戶的需求。l 分類： 需求開發(fā)：目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。包括： 需求調(diào)查（需求獲?。┑哪康氖峭ㄟ^各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生需求陳述。 需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節(jié)等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。 需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進一步定義準確無誤的產(chǎn)品需求，產(chǎn)生軟件需求規(guī)格說明書。 需求管理：目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的

9、變更。包括： 需求確認是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。 需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，建立與維護“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。 需求變更控制是指依據(jù)“變更申請審批更改重新確認”的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項目發(fā)生混亂。l 需求工程結(jié)構(gòu)圖：六、 需求獲取技術(shù)l 獲取需求的方法 面談（訪談）：開放式問題和封閉式問題 問卷調(diào)查：潛在使用者太多或分布太廣時 會議（需求討論會、重點問題討論會、業(yè)務(wù)專題討論會、設(shè)計專題討論會） 文檔研究 任務(wù)示范（觀察）：通過觀察可以獲得

10、第一手的資料。 用例與角色扮演 原型設(shè)計（小規(guī)模試驗） 研究類似公司l 需求陳述 是一份文檔，陳述用戶對軟件的期望和需要，并對可能的規(guī)格要求加以說明。 需求陳述用來明確軟件的用途，它不僅要說明軟件有什么用，還要在宏觀層次上明確軟件應(yīng)具備的特性。 核心內(nèi)容 開發(fā)該軟件的動機（愿景）是什么？ 該項目的主要涉眾是誰？ 希望該軟件具備哪些主要功能和特性？七、 需求建模l 需求模型分類： 功能模型如UC見下章 業(yè)務(wù)流程模型如DFD 數(shù)據(jù)流圖(Data Flow Diagram, DFD)是結(jié)構(gòu)化方法中用于表示系統(tǒng)邏輯模型的一種工具，它以圖形的方式描繪數(shù)據(jù)在系統(tǒng)中流動和處理的過程。 數(shù)據(jù)建模模型如ER E

11、R建模用于對數(shù)據(jù)進行建模（概念模型） 在ER圖中包含三個圖形符號，分別表示：實體（矩形）、屬性（橢圓）、聯(lián)系（菱形）八、 編寫軟件需求規(guī)格說明書l 需求分析的主要成果：軟件需求規(guī)格說明書(Software Requirement Specification, SRS)l 要求的屬性： 正確：最重要的屬性。 清楚：讓人易讀易懂，不在于文檔的厚度。 無二義性：是指每個需求只有唯一的含義。 一致：指軟件需求規(guī)格說明書中各個需求之間不會發(fā)生矛盾。 必要：其中的各項需求對用戶而言應(yīng)當都是必要的。 完備：指軟件需求規(guī)格說明書中沒有遺漏一些必要的需求。 可實現(xiàn)：其中各項需求對開發(fā)方而言應(yīng)當都是可實現(xiàn)的。 可

12、驗證：其中的各項需求對用戶方而言應(yīng)當都是可驗證的。 確定優(yōu)先級：先做優(yōu)先級高的需求，后做（甚至放棄）優(yōu)先級低的需求，這樣可以將風(fēng)險降到最低。l 闡述“做什么”而不是“怎么做”九、 需求確認l 需求確認是指開發(fā)方和客戶方共同對軟件需求規(guī)格說明書進行評審，雙方對需求達成共識后作出承諾。l 包含兩個重要工作： 需求評審 需求承諾十、 需求跟蹤技術(shù)l 需求跟蹤的目的是建立與維護“需求-設(shè)計-編程-測試”之間的一致性，確保所有的工作成果符合用戶需求。l 跟蹤有兩種方式： 正向跟蹤。檢查軟件需求規(guī)格說明書中的每個需求是否都能在后繼工作成果中找到對應(yīng)點。 逆向跟蹤。檢查設(shè)計文檔、代碼、測試用例等工作成果是否

13、都能在軟件需求規(guī)格說明書中找到出處。l 跟蹤矩陣 源跟蹤矩陣（需求與需求來源） 功能跟蹤矩陣（需求與功能） 依賴跟蹤矩陣（一個需求與另一個需求）十一、 需求變更控制l 需求發(fā)生變更的起因主要有： 隨著項目的進展，人們（包括開發(fā)方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯誤或不足，因此要變更需求。 市場發(fā)生了變化，原先的需求文檔可能跟不上當前的市場需求，因此要變更需求。l 需求變更控制的目的： 如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。 如果需求變更帶來的壞處大于好處，那么拒絕變更。l 需求基線 已經(jīng)通過正式評審和批

14、準的規(guī)格說明或產(chǎn)品，它可以作為進一步開發(fā)的基礎(chǔ)，并且只有通過正式的變更控制過程才能修改它。 是被明確和固定下來的需求集合，是項目團隊需要在某一特定產(chǎn)品版本中實現(xiàn)的特征和需求集合。第五章 統(tǒng)一建模語言UML（20分）（Unified Modeling Language）（重點看實驗1）一、 用例圖（Use Case Diagram）l 執(zhí)行者和用例之間的關(guān)聯(lián)關(guān)系（Association）：一根直線來表示l 執(zhí)行者之間的泛化關(guān)系（Generalization）（或繼承關(guān)系）用例之間的關(guān)系：l 包含關(guān)系：描述在多個用例中都有的公共行為，由用例A指向用例B，表示用例A中使用了用例B中的行為或功能，包含

15、關(guān)系是通過在依賴關(guān)系上應(yīng)用構(gòu)造型（衍型）來表示的。l 擴展關(guān)系：擴展用例可以在基用例之上添加新的行為，但是基用例必須聲明某些特定的“擴展點”，并且擴展用例只能在這些擴展點上擴展新的行為。擴展關(guān)系是通過在依賴關(guān)系上應(yīng)用構(gòu)造型（衍型）來表示的。l 泛化關(guān)系： 當多個用例共同擁有一種類似的結(jié)構(gòu)和行為的時候，可以將它們的共性抽象成為父用例，其他的用例作為泛化關(guān)系中的子用例。 在用例的泛化關(guān)系中，子用例是父用例的一種特殊形式，子用例繼承了父用例所有的結(jié)構(gòu)、行為和關(guān)系。 泛化關(guān)系一般很少使用。二、 狀態(tài)圖(State Diagram)l 定義：用來描述一個特定對象的所有可能狀態(tài)及其引起狀態(tài)轉(zhuǎn)移的事件。 通

16、常用狀態(tài)圖來描述單個對象的行為 只有那些具有重要交互行為的類，才會使用狀態(tài)圖來描述。 一個狀態(tài)圖包括一系列對象的狀態(tài)及狀態(tài)之間的轉(zhuǎn)換。l 組成元素： 初始狀態(tài) 終止狀態(tài) 狀態(tài) 轉(zhuǎn)移 守護條件 事件 動作三、 活動圖（Activity Diagram）l 定義：用來表示系統(tǒng)中各種活動的次序，它的應(yīng)用非常廣泛，既可用來描述用例的工作流程，也可以用來描述類中某個方法的操作行為。l 作用： 描述業(yè)務(wù)流程 描述用例路徑 描述方法執(zhí)行流程（程序流程圖）l 組成元素： 起始活動(Start Activity) 終止活動(End Activity) 活動(Activity) 轉(zhuǎn)移(Transition)或流(

17、Flow) 決策(Decision) 守護條件(Condition) 同步條(Synchronization) 泳道(Swimlane)四、 順序圖l 定義： 用于確認和豐富一個使用情境的邏輯。 將交互關(guān)系表現(xiàn)為一個二維圖，縱向是時間軸，時間沿豎線向下延伸。橫向軸代表了在協(xié)作中各獨立對象的類元角色，類元角色的活動用生命線表示。l 組成元素： 生命線：用一條縱向虛線表示。 對象：表示為一個矩形，其中對象名稱標有下劃線。 激活：是過程的執(zhí)行，包括等待過程執(zhí)行的時間。激活部分替換生命線，使用長條的矩形表示。 消息：對象之間的通信 調(diào)用消息：對應(yīng)于激活，表示它將會激活一個對象。 發(fā)送消息：沒有對應(yīng)激活

18、框，表示它不是一個調(diào)用消息，不會引發(fā)其他對象的活動。 返回消息 自身消息 創(chuàng)建消息 銷毀消息 同步消息 異步消息 交互片段：一個復(fù)雜的順序圖可以劃分為幾個小塊，每一個小塊稱為一個交互片段。 alt:多條路徑，條件為真時執(zhí)行。 opt:任選，僅當條件為真時執(zhí)行。 par:并行，每一片段都并發(fā)執(zhí)行。 loop:循環(huán)，片段可多次執(zhí)行。 critical:臨界區(qū)，只能有一個線程對它立即執(zhí)行。五、 類圖l 類之間的關(guān)系： 關(guān)聯(lián)關(guān)系(Association) 用于表示一類對象與另一類對象之間有聯(lián)系 用實線連接有關(guān)聯(lián)的對象所對應(yīng)的類 通常將一個類的對象作為另一個類的屬性 自關(guān)聯(lián) 一些類的屬性對象類型為該類本

19、身 多重性關(guān)聯(lián) 表示一個類的對象與另一個類的對象連接的個數(shù)。 聚合關(guān)系(Aggregation) 表示一個整體與部分的關(guān)系。 成員類是整體類的一部分，即成員對象是整體對象的一部分，但是成員對象可以脫離整體對象獨立存在。 在UML中，聚合關(guān)系用帶空心菱形的直線表示。 組合關(guān)系(Composition) 部分和整體具有統(tǒng)一的生存期。 部分對象與整體對象之間具有同生共死的關(guān)系。 整體類可以控制成員類的生命周期，即成員類的存在依賴于整體類。 在UML中，組合關(guān)系用帶實心菱形的直線表示。 依賴關(guān)系(Dependency) 使用關(guān)系。 體現(xiàn)在某個類的方法使用另一個類的對象作為參數(shù)。 在UML中，依賴關(guān)系用

20、帶箭頭的虛線表示。 泛化關(guān)系(Generalization) 用于描述父類與子類之間的關(guān)系，父類又稱作基類或超類，子類又稱作派生類。 在UML中，泛化關(guān)系用帶空心三角形的直線來表示。 接口與實現(xiàn)關(guān)系(Realization) 類實現(xiàn)了接口，類中的操作實現(xiàn)了接口中所聲明的操作。 在UML中，類與接口之間的實現(xiàn)關(guān)系用帶空心三角形的虛線來表示。六、 包圖l 定義 一種把元素組織到一起的通用機制 用于描述包與包之間的關(guān)系 包的圖標是一個帶標簽的文件夾。l 包之間的關(guān)系 引入關(guān)系： 一個包中的類可以被另一個指定包（以及嵌套于其中的那些包）中的類引用。 在依賴線上增加一個衍型。 泛化關(guān)系：表示一個包繼承了

21、另一個包的內(nèi)容，同時又補充自己增加的內(nèi)容。 嵌套關(guān)系：一個包中可以包含若干個子包，構(gòu)成了包的嵌套層次結(jié)構(gòu)。七、 組件圖（Component Diagram）l 定義： 顯示編譯、鏈接或執(zhí)行時組件之間的依賴關(guān)系，以及組件的接口和調(diào)用關(guān)系。 組件就是一個實際文件，可以有以下幾種類型： 源代碼組件：一個源代碼文件或者與一個包對應(yīng)的若干個源代碼文件。 二進制組件：一個目標碼文件，一個靜態(tài)的或者動態(tài)的庫文件。 可執(zhí)行組件：在一臺處理器上可運行的一個可執(zhí)行的程序單位，即所謂可執(zhí)行程序。l 組件間關(guān)系：泛化關(guān)系、依賴關(guān)系l 組成元素： 組件：系統(tǒng)中可以替換的部分，一般對應(yīng)一個實際文件，如exe、jar、dl

22、l等文件，它遵循并提供了一組接口的實現(xiàn)。 接口：一組操作的集合，它指明了由類或組件所請求或者所提供的服務(wù)。 部件：組件的局部實現(xiàn)。 端口：被封裝的組件與外界的交互點，遵循指定接口的組件通過它來收發(fā)消息。 連接件：在特定語境下組件中兩個部件之間或者兩個端口之間的通信關(guān)系。 供(Provided)接口與需(Required)接口八、 部署圖(Deployment Diagram)l 定義： 描述系統(tǒng)硬件的物理拓撲結(jié)構(gòu)及在此結(jié)構(gòu)上執(zhí)行的軟件。 顯示了系統(tǒng)的硬件和安裝在硬件上的軟件，以及用于連接異構(gòu)計算機之間的中間件。l 組成元素： 節(jié)點和連接：節(jié)點(Node)代表一個物理設(shè)備。在 UML 中，使用一

23、個立方體表示一個節(jié)點。節(jié)點之間的連線表示系統(tǒng)之間進行交互的通信路徑，在 UML 中被稱為連接。 組件：在部署圖中，組件代表可執(zhí)行的物理代碼模塊，如一個可執(zhí)行程序，邏輯上它可以與類或包對應(yīng)。九、 對象圖l 定義：對象圖是類圖在某一時刻的一個實例。十、 組合結(jié)構(gòu)圖l 定義： 將每一個類放在一個整體中，從類的內(nèi)部結(jié)構(gòu)來審視一個類。 組合結(jié)構(gòu)圖可用于表示一個類的內(nèi)部結(jié)構(gòu)。l 組成元素： 部件(Part)：表示被描述事物所擁有的內(nèi)部成分。 連接件(Connector)：表示部件之間的關(guān)系。 端口(Port)：表示部件和外部環(huán)境的交互點。十一、 通信圖l 定義： 通信圖強調(diào)參與一個交互對象的組織。 它與順

24、序圖是同構(gòu)圖，也就是它們包含了相同的信息，只是表達方式不同而已，通信圖與順序圖可以相互轉(zhuǎn)換。 當對象及其連接有利于理解交互時，選擇通信圖；當只需了解交互的次序時，選擇順序圖。l 組成元素：執(zhí)行者(Actor)、對象(Object)、連接(Link，也稱為鏈)、消息(Message)和守護條件(Condition)。十二、 定時圖l 定義： 采用一種帶數(shù)字刻度的時間軸來精確地描述消息的順序 可視化地表示每條生命線的狀態(tài)變化 可以把狀態(tài)發(fā)生變化的時刻以及各個狀態(tài)所持續(xù)的時間具體地表示出來。十三、 交互概覽圖l 定義： 交互圖與活動圖的混合物，可以把交互概覽圖理解為細化的活動圖，在其中的活動都通過一

25、些小型的順序圖來表示；也可以將其理解為利用標明控制流的活動圖分解過的順序圖。 用于將一些零散的順序圖組織在一起，它采用了活動圖的構(gòu)造方式，利用了活動圖的各種控制節(jié)點，并把活動圖的每個活動結(jié)點替換為一個交互或者交互使用。每個交互或者交互使用都使用一個順序圖表示。面向?qū)ο笤O(shè)計原則1、 單一職責(zé)原則(Single Responsibility Principle, SRP)定義：一個對象應(yīng)該只包含單一的職責(zé)，并且該職責(zé)被完整地封裝在一個類中。Every object should have a single responsibility, and that responsibility should

26、 be entirely encapsulated by the class.2、 開閉原則(Open-Closed Principle, OCP)定義：一個軟件實體應(yīng)當對擴展開放，對修改關(guān)閉。Software entities should be open for extension, but closed for modification.3、 里氏代換原則(Liskov Substitution Principle, LSP)定義：所有引用基類（父類）的地方必須能透明地使用其子類的對象。Functions that use pointers or references to base c

27、lasses must be able to use objects of derived classes without knowing it.4、 依賴倒轉(zhuǎn)原則(Dependence Inversion Principle, DIP)定義：高層模塊不應(yīng)該依賴低層模塊，它們都應(yīng)該依賴抽象。抽象不應(yīng)該依賴于細節(jié)，細節(jié)應(yīng)該依賴于抽象。High level modules should not depend upon low level modules, both should depend upon abstractions. Abstractions should not depend upo

28、n details, details should depend upon abstractions.5、 接口隔離原則(Interface Segregation Principle, ISP)定義：客戶端不應(yīng)該依賴那些它不需要的接口。Clients should not be forced to depend upon interfaces that they do not use.6、 合成復(fù)用原則(Composite Reuse Principle, CRP)定義：盡量使用對象組合，而不是繼承來達到復(fù)用的目的。Favor composition of objects over inhe

29、ritance as a reuse mechanism.7、 迪米特法則(Law of Demeter, LoD)定義：一個軟件實體應(yīng)當盡可能少的與其他實體發(fā)生相互作用。設(shè)計模式（重點看實驗2、3）一、 創(chuàng)建型模式l 簡單工廠模式（Simple Factory） 定義：根據(jù)參數(shù)的不同返回不同類的實例，專門定義一個類來負責(zé)創(chuàng)建其他類的實例，被創(chuàng)建的實例通常都具有共同的父類。 優(yōu)點： 實現(xiàn)了對責(zé)任的分割，它提供了專門的工廠類用于創(chuàng)建對象。 客戶端無須知道所創(chuàng)建的具體產(chǎn)品類的類名，只需要知道具體產(chǎn)品類所對應(yīng)的參數(shù)即可。 通過引入配置文件，可以在不修改任何客戶端代碼的情況下更換和增加新的具體產(chǎn)品類，

30、在一定程度上提高了系統(tǒng)的靈活性。 缺點： 工廠類集中了所有產(chǎn)品創(chuàng)建邏輯，職責(zé)過重，不符合單一職責(zé)原則。 增加系統(tǒng)中類的個數(shù)。 系統(tǒng)擴展困難，不符合開閉原則。 由于使用了靜態(tài)工廠方法，造成工廠角色無法形成基于繼承的等級結(jié)構(gòu)。 適用范圍： 工廠類負責(zé)創(chuàng)建的對象比較少。 客戶端只知道傳入工廠類的參數(shù)，對于如何創(chuàng)建對象不關(guān)心。l 工廠方法模式(Factory Method Pattern) 定義： 工廠父類負責(zé)定義創(chuàng)建產(chǎn)品對象的公共接口，而工廠子類則負責(zé)生成具體的產(chǎn)品對象，這樣做的目的是將產(chǎn)品類的實例化操作延遲到工廠子類中完成，即通過工廠子類來確定究竟應(yīng)該實例化哪一個具體產(chǎn)品類。 Define an

31、interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. 優(yōu)點： 用戶只需要關(guān)心所需產(chǎn)品對應(yīng)的工廠，無須關(guān)心創(chuàng)建細節(jié)，甚至無須知道具體產(chǎn)品類的類名。 工廠可以自主確定創(chuàng)建何種產(chǎn)品對象，而如何創(chuàng)建這個對象的細節(jié)則完全封裝在具體工廠內(nèi)部。 在系統(tǒng)中加入新產(chǎn)品時，無須修改抽象工廠和抽象產(chǎn)品提供的接口，無須修改客戶端，也無須修改其他的具體工廠和具體產(chǎn)品，而只要添

32、加一個具體工廠和具體產(chǎn)品就可以了。 缺點： 在添加新產(chǎn)品時，需要編寫新的具體產(chǎn)品類，而且還要提供與之對應(yīng)的具體工廠類，系統(tǒng)中類的個數(shù)將成對增加，在一定程度上增加了系統(tǒng)的復(fù)雜度。 增加了系統(tǒng)的抽象性和理解難度。 適用范圍： 一個類不知道它所需要的對象的類。 一個類通過其子類來指定創(chuàng)建哪個對象。 將創(chuàng)建對象的任務(wù)委托給多個工廠子類中的某一個，客戶端在使用時可以無須關(guān)心是哪一個工廠子類創(chuàng)建產(chǎn)品子類，需要時再動態(tài)指定。l 抽象工廠模式(Abstract Factory Pattern) 定義： 提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無須指定它們具體的類。 Provide an interfac

33、e for creating families of related or dependent objects without specifying their concrete classes. 優(yōu)點： 隔離了具體類的生成。 可以實現(xiàn)高內(nèi)聚低耦合的設(shè)計目的。 能夠保證客戶端始終只使用同一個產(chǎn)品族中的對象。 增加新的具體工廠和產(chǎn)品族很方便，無須修改已有系統(tǒng)，符合“開閉原則”。 缺點： 難以擴展抽象工廠來生產(chǎn)新種類的產(chǎn)品。 開閉原則的傾斜性（增加新的工廠和產(chǎn)品族容易，增加新的產(chǎn)品等級結(jié)構(gòu)麻煩） 適用范圍： 一個系統(tǒng)不應(yīng)當依賴于產(chǎn)品類實例如何被創(chuàng)建、組合和表達的細節(jié)。 系統(tǒng)中有多于一個的產(chǎn)品族，而

34、每次只使用其中某一產(chǎn)品族。 屬于同一個產(chǎn)品族的產(chǎn)品將在一起使用。 系統(tǒng)提供一個產(chǎn)品類的庫，所有的產(chǎn)品以同樣的接口出現(xiàn)，從而使客戶端不依賴于具體實現(xiàn)。l 單例模式(Singleton Pattern) 定義： 確保某一個類只有一個實例，而且自行實例化并向整個系統(tǒng)提供這個實例，這個類稱為單例類，它提供全局訪問的方法。 Ensure a class has only one instance and provide a global point of access to it. 優(yōu)點： 提供了對唯一實例的受控訪問。 可以節(jié)約系統(tǒng)資源 允許可變數(shù)目的實例。 缺點： 單例類的擴展有很大的困難。 單例類的

35、職責(zé)過重。 濫用單例將帶來一些負面問題。 適用范圍： 系統(tǒng)只需要一個實例對象。 客戶調(diào)用類的單個實例只允許使用一個公共訪問點。二、 結(jié)構(gòu)型模式l 適配器模式(Adapter Pattern) 定義： 將一個接口轉(zhuǎn)換成客戶希望的另一個接口，適配器模式使接口不兼容的那些類可以一起工作，其別名為包裝器(Wrapper)。適配器模式既可以作為類結(jié)構(gòu)型模式，也可以作為對象結(jié)構(gòu)型模式。 Convert the interface of a class into another interface clients expect. Adapter lets classes work together that

36、 couldnt otherwise because of incompatible interfaces.類適配器對象適配器 優(yōu)點： 將目標類和適配者類解耦。 增加了類的透明性和復(fù)用性。 靈活性和擴展性都非常好。 缺點： 類適配器模式的缺點是適配器類在很多編程語言中不能同時適配多個適配者類。 對象適配器模式的缺點是很難置換適配者類的方法。 適用范圍： 系統(tǒng)需要使用現(xiàn)有的類，而這些類的接口不符合系統(tǒng)的需要。 想要建立一個可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類一起工作。l 橋接模式(Bridge Pattern) 定義： 將抽象部分與它的實現(xiàn)部分分離，使它們都可以獨立地變化。

37、Decouple an abstraction from its implementation so that the two can vary independently. 優(yōu)點： 分離抽象接口及其實現(xiàn)部分。 橋接模式是比多繼承方案更好的解決方法。 提高了系統(tǒng)的可擴充性，在兩個變化維度中任意擴展一個維度，都不需要修改原有系統(tǒng)。 實現(xiàn)細節(jié)對客戶透明，可以對用戶隱藏實現(xiàn)細節(jié)。 缺點： 會增加系統(tǒng)的理解與設(shè)計難度。 其使用范圍具有一定的局限性。 適用范圍： 需要在構(gòu)件的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個層次之間建立靜態(tài)的繼承聯(lián)系。 抽象化角色和實現(xiàn)化角色可以以繼承的方式獨立擴展

38、而互不影響。 一個類存在兩個獨立變化的維度，且這兩個維度都需要進行擴展。 設(shè)計要求需要獨立管理抽象化角色和具體化角色。 不希望使用繼承或因為多層次繼承導(dǎo)致系統(tǒng)類的個數(shù)急劇增加的系統(tǒng)。l 組合模式(Composite Pattern) 定義：組合多個對象形成樹形結(jié)構(gòu)以表示“整體-部分”的結(jié)構(gòu)層次。組合模式對單個對象（即葉子對象）和組合對象（即容器對象）的使用具有一致性。Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual o

39、bjects and compositions of objects uniformly. 優(yōu)點： 可以清楚地定義分層次的復(fù)雜對象。 客戶端可以一致的使用組合結(jié)構(gòu)或其中單個對象。 更容易在組合體內(nèi)加入對象構(gòu)件。 缺點： 設(shè)計變得更加抽象。 很難對容器中的構(gòu)件類型進行限制。 適用范圍： 需要表示一個對象整體或部分層次。 客戶端可以針對抽象構(gòu)件編程，無須關(guān)心對象層次結(jié)構(gòu)的細節(jié)。 對象的結(jié)構(gòu)是動態(tài)的并且復(fù)雜程度不一樣，但客戶需要一致地處理它們。l 外觀模式(Facade Pattern) 定義： 外部與一個子系統(tǒng)的通信必須通過一個統(tǒng)一的外觀對象進行，為子系統(tǒng)中的一組接口提供一個一致的界面，外觀模式定

40、義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。 Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. 優(yōu)點： 對客戶屏蔽子系統(tǒng)組件，減少了客戶處理的對象數(shù)目并使得子系統(tǒng)使用起來更加容易。 實現(xiàn)了子系統(tǒng)與客戶之間的松耦合關(guān)系。 降低了大型軟件系統(tǒng)中的編譯依賴性，并簡化了系統(tǒng)在不同平臺之間的移植過程。 只是提供了一個訪問子系統(tǒng)的統(tǒng)一入口，并不影響用戶直接

41、使用子系統(tǒng)類。 缺點： 不能很好地限制客戶使用子系統(tǒng)類。 在不引入抽象外觀類的情況下，增加新的子系統(tǒng)可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”。 適用范圍： 當要為一個復(fù)雜子系統(tǒng)提供一個簡單接口時可以使用外觀模式。 客戶程序與多個子系統(tǒng)之間存在很大的依賴性。 使用外觀模式定義系統(tǒng)中每一層的入口，層與層之間不直接產(chǎn)生聯(lián)系，而通過外觀類建立聯(lián)系，降低層之間的耦合度。l 代理模式(Proxy Pattern) 定義： 給某一個對象提供一個代理，并由代理對象控制對原對象的引用。 Provide a surrogate or placeholder for another object to

42、 control access to it. 優(yōu)點： 協(xié)調(diào)調(diào)用者和被調(diào)用者。 遠程代理使得客戶端可以訪問在遠程機器上的對象。 虛擬代理通過使用一個小對象來代表一個大對象，可以減少系統(tǒng)資源的消耗，對系統(tǒng)進行優(yōu)化并提高運行速度。 保護代理可以控制對真實對象的使用權(quán)限。 缺點： 有些類型的代理模式可能會造成請求的處理速度變慢。 實現(xiàn)代理模式需要額外的工作，有些代理模式的實現(xiàn)非常復(fù)雜。 適用范圍： 遠程(Remote)代理。 虛擬(Virtual)代理。 Copy-on-Write代理。 保護(Protect or Access)代理。 緩沖(Cache)代理。 防火墻(Firewall)代理。 同步

43、化(Synchronization)代理。 智能引用(Smart Reference)代理。三、 行為型模式l 職責(zé)鏈模式(Chain of Responsibility Pattern) 定義：避免請求發(fā)送者與接收者耦合在一起，讓多個對象都有可能接收請求，將這些對象連接成一條鏈，并且沿著這條鏈傳遞請求，直到有對象處理它為止。Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receivin

44、g objects and pass the request along the chain until an object handles it. 優(yōu)點： 降低耦合度。 可簡化對象的相互連接。 增強給對象指派職責(zé)的靈活性。 增加新的請求處理類很方便。 缺點： 不能保證請求一定被接收。 系統(tǒng)性能將受到一定影響，而且在進行代碼調(diào)試時不太方便；可能會造成循環(huán)調(diào)用。 適用范圍： 有多個對象可以處理同一個請求，具體哪個對象處理該請求由運行時刻自動確定。 在不明確指定接收者的情況下，向多個對象中的一個提交一個請求。 可動態(tài)指定一組對象處理請求。l 命令模式(Command Pattern) 定義： 將一個請求封裝為一個對象，從而使我們可用不同的請求對客戶進行參數(shù)化；對請求排隊或者記錄請求日志，以及支持可撤銷的操作。 Encapsulate a request as an object, thereby letting you parameterize clients with diff