軟件設(shè)計(jì)之我見

1、chapter 模塊化理解模塊化（結(jié)構(gòu)化）模塊化的設(shè)計(jì)思想使得我們能夠從簡(jiǎn)單的、獨(dú)立的、可復(fù)用的模塊開始，構(gòu)建復(fù)雜的系統(tǒng)，從而達(dá)到復(fù)雜系統(tǒng)的易開發(fā)、易修改、易復(fù)用。模塊化的優(yōu)點(diǎn)從簡(jiǎn)單性考慮：減少了調(diào)試和修改的時(shí)間。通過將系統(tǒng)劃分為獨(dú)立的各個(gè)模塊，每個(gè)模塊能夠在極少的去考慮對(duì)其他模塊的影響下，獨(dú)立的被考慮、實(shí)現(xiàn)、修改。從可觀察性考慮：每個(gè)模塊在邏輯上是清楚正確的，能夠很容易的看出邏輯行為是如何以及為何發(fā)生。減少了開發(fā)和修改的時(shí)間。從模塊的角度考慮：系統(tǒng)的其他部分可以通過模塊的名字對(duì)該模塊進(jìn)行調(diào)用。每個(gè)模塊只專注于解決一個(gè)問題，減少了問題的復(fù)雜度，易于實(shí)現(xiàn)和修改。在模塊化的思想下，每個(gè)模塊能夠得到

2、獨(dú)立的對(duì)待：獨(dú)立理解獨(dú)立使用或復(fù)用獨(dú)立被構(gòu)建一個(gè)模塊的失效不會(huì)影響到其他模塊一個(gè)模塊的修改不會(huì)影響到其他模塊降低耦合：最小化模塊之間的聯(lián)系耦合：模塊之間建立的聯(lián)系的強(qiáng)度的度量耦合分為兩大類：模塊與公共環(huán)境之間的聯(lián)系、模塊與模塊之間的聯(lián)系。-原則1：共享變量是有害的！參照公共耦合。-原則2：語(yǔ)法語(yǔ)義清晰，降低隱式關(guān)系理解一個(gè)模塊不需要依賴其他模塊的含義。（PPT例子）-原則3：避免重復(fù)否則，外部的修改會(huì)導(dǎo)致各個(gè)模塊中重復(fù)的部分也需要修改。-原則4：面向接口編程接口：模塊自身實(shí)現(xiàn)：模塊內(nèi)部通過模塊的名字與整個(gè)模塊建立的聯(lián)系產(chǎn)生的耦合 公共耦合 控制耦合 = 印記耦合 數(shù)據(jù)耦合內(nèi)容耦合最差公共耦合也

3、不可接受數(shù)據(jù)耦合好一些提高內(nèi)聚：最大化模塊內(nèi)部元素的關(guān)系偶然內(nèi)聚隨意放在一起。main函數(shù)？邏輯內(nèi)聚在邏輯上相似（加減乘除）。if-else switch-caseEDIT ALL DATA EDIT: PROC (TYPE, DATA)/* do some common edits */IF TYPE = “A”THEN /* edit by type A rules */IF TYPE = “B”THEN /* edit by type B rules */時(shí)間內(nèi)聚一系列的事務(wù)在同一時(shí)間段內(nèi)完成。例如：所有的初始化通信內(nèi)聚由于對(duì)共同數(shù)據(jù)的引用而建立的內(nèi)聚。如果一個(gè)模塊的所有成分都操作同一數(shù)

4、據(jù)集或生成同一數(shù)據(jù)集，則稱為通信內(nèi)聚。“Read” and “Print” input data順序內(nèi)聚為解決某個(gè)問題而實(shí)現(xiàn)一系列順序的步驟。如果一個(gè)模塊的各個(gè)成分和同一個(gè)功能密切相關(guān)，而且一個(gè)成分的輸出作為另一個(gè)成分的輸入，則稱為順序內(nèi)聚。read deal update output功能內(nèi)聚具有一個(gè)共同的目標(biāo)，完成一個(gè)功能。信息內(nèi)聚信息內(nèi)聚 功能內(nèi)聚 順序內(nèi)聚 = 通信內(nèi)聚 = 時(shí)間內(nèi)聚 邏輯內(nèi)聚 偶然內(nèi)聚【面向?qū)ο蟆恐械鸟詈详P(guān)系交互耦合同結(jié)構(gòu)化思想中的耦合關(guān)系相同，包括：共享數(shù)據(jù)變量訪問方法調(diào)用隱式關(guān)系組件耦合：類之間的關(guān)系，一個(gè)類使用另一個(gè)類的實(shí)例對(duì)象（PPT例子）組件耦合的四種類型：

5、全局的變量：聚合關(guān)系參數(shù)：方法調(diào)用之間的傳參創(chuàng)建：方法內(nèi)部的局部變量隱式關(guān)系：由其他對(duì)象供給組件耦合又可分為以下三種類型：隱式組件耦合：（PPT）例子最差的耦合關(guān)系。C的對(duì)象出現(xiàn)在C的某個(gè)方法實(shí)現(xiàn)中，但是C在C的規(guī)格說明和實(shí)現(xiàn)中都沒有說明。分散的組件耦合：C作為局部變量或?qū)嵗兞吭贑的實(shí)現(xiàn)中出現(xiàn)，但是沒有在C的規(guī)格中說明。表現(xiàn)：聚合關(guān)系：全局變量局部變量分散式組件耦合是可以接受的。規(guī)格化組件耦合：C在C的規(guī)格中說明。繼承耦合修改式繼承耦合：（P+C=1+N）最差的繼承耦合。子類對(duì)父類進(jìn)行沒有任何規(guī)則的修改。如果外界擁有父類的引用，必須知道父類+子類所有方法。改進(jìn)式繼承耦合：（P+C重寫的一些方

6、法=1+小N）在預(yù)定義的基礎(chǔ)上的修改。如果外界擁有父類的引用，必須知道父類+子類修改的。擴(kuò)展式繼承耦合：（ONLY P=1）繼承的都沒有修改，只是添加方法和變量。如果外界擁有父類的引用，只需要知道父類。chapter 信息隱藏信息隱藏的含義每個(gè)模塊都隱藏了關(guān)于一個(gè)設(shè)計(jì)決策的實(shí)現(xiàn)。所有的設(shè)計(jì)決策都是相對(duì)獨(dú)立的。KWIC的兩種模塊化劃分方法第一種模塊化劃分方法：按照【處理流程】的方法進(jìn)行劃分，處理過程中每個(gè)主要的處理步驟封裝成一個(gè)模塊。必須在并行工作之前設(shè)計(jì)好所有的數(shù)據(jù)結(jié)構(gòu)，并需要復(fù)雜的描述。第二種模塊化劃分方法：按照【信息隱藏】的思想進(jìn)行劃分，每個(gè)模塊封裝一個(gè)或幾個(gè)“秘密”，每個(gè)模塊都隱藏了一個(gè)

7、獨(dú)立于其他模塊的設(shè)計(jì)決策。必須在并行工作之前設(shè)計(jì)好所有的接口，只需要簡(jiǎn)單的描述。兩種模塊化劃分的結(jié)果，可能都共享相同的數(shù)據(jù)結(jié)構(gòu)和相同的算法，不同的是職責(zé)分配時(shí)模塊劃分的方式。系統(tǒng)運(yùn)行是的表現(xiàn)可能是相同的，但是在可修改性、文檔化、可理解性等方面的展現(xiàn)不同。-設(shè)計(jì)定律1：不要按照處理流程中的步驟分解模塊。Module Guide針對(duì)復(fù)雜的系統(tǒng)-設(shè)計(jì)定律2：創(chuàng)建一個(gè)層次化結(jié)構(gòu)的文檔module guide（自頂向下的居多，也可以改成自底向上的）按照module guide的思想，每個(gè)模塊包括以下3個(gè)部分：秘密：主要秘密和次要秘密主要秘密（來自SRS軟件需求規(guī)格）軟件設(shè)計(jì)時(shí)希望隱藏的信息。次要秘密（來

8、自變化）實(shí)現(xiàn)隱藏主要秘密的模塊的設(shè)計(jì)時(shí)的實(shí)現(xiàn)決策。模塊在系統(tǒng)運(yùn)作用扮演的角色（功能）模塊提供的接口（？面向接口編程）chapter 體系結(jié)構(gòu)設(shè)計(jì)風(fēng)格【部件】【連接件】【約束】模塊層次的設(shè)計(jì)風(fēng)格調(diào)用返回風(fēng)格（主程序子程序風(fēng)格、面向?qū)ο箫L(fēng)格）主程序子程序風(fēng)格描述主程序/子程序風(fēng)格將系統(tǒng)組織成層次結(jié)構(gòu)，包括一個(gè)主程序和一系列子程序。主程序是系統(tǒng)的控制器，負(fù)責(zé)調(diào)度各子程序的執(zhí)行。各子程序又是一個(gè)局部的控制器，調(diào)度其子子程序的執(zhí)行。主程序/子程序風(fēng)格的重要設(shè)計(jì)決策與約束有：基于程序調(diào)用關(guān)系建立連接件，以層次分解的方式建立系統(tǒng)部件，共同組成層次結(jié)構(gòu)。不允許逆方向調(diào)用：上層部件可以“使用”下層部件，但下層部

9、件不能“使用”上層部件。 單線程執(zhí)行：主程序部件擁有最初的執(zhí)行控制權(quán)，將控制權(quán)轉(zhuǎn)移給下層子程序。子程序只能夠通過上層轉(zhuǎn)移來獲得控制權(quán)，可以在執(zhí)行中將控制權(quán)轉(zhuǎn)交給下層的子子程序，并在自身執(zhí)行完成之后必須將控制權(quán)還交給上層部件。抽象規(guī)格【主程序部件】：它的實(shí)例是整個(gè)系統(tǒng)的控制器，控制權(quán)的發(fā)起者和終結(jié)者。subroutine端口包含需求接口，定義了對(duì)子程序的功能與交互期望?！咀映绦虿考浚禾幱谥鞒绦蛳聦?，controller端口描述了對(duì)上層部件提供的服務(wù)?！境绦蛘{(diào)用連接件】：程序調(diào)用機(jī)制。caller定義了給調(diào)用者提供的交互機(jī)制，callee定義了給被調(diào)用者提供的交互機(jī)制。面向?qū)ο笫斤L(fēng)格描述面向?qū)ο?/p>

10、式風(fēng)格借鑒面向?qū)ο蟮乃枷?，組織整個(gè)系統(tǒng)的高層結(jié)構(gòu)。面向?qū)ο笫斤L(fēng)格將系統(tǒng)組織為多個(gè)獨(dú)立的對(duì)象，每個(gè)對(duì)象封裝其內(nèi)部的數(shù)據(jù)，并基于數(shù)據(jù)對(duì)外提供服務(wù)。不同對(duì)象之間通過協(xié)作機(jī)制共同完成系統(tǒng)任務(wù)。面向?qū)ο笫斤L(fēng)格的重要設(shè)計(jì)決策及約束有：依照對(duì)數(shù)據(jù)的使用情況，用信息內(nèi)聚的標(biāo)準(zhǔn)，為系統(tǒng)建立對(duì)象部件。每個(gè)對(duì)象部件基于內(nèi)部數(shù)據(jù)提供對(duì)外服務(wù)接口，并隱藏內(nèi)部數(shù)據(jù)的表示?；诜椒ㄕ{(diào)用機(jī)制建立連接件，將對(duì)象部件連接起來。每個(gè)對(duì)象負(fù)責(zé)維護(hù)其自身數(shù)據(jù)的一致性與完整性，并以此為基礎(chǔ)對(duì)外提供“正確”的服務(wù)。每個(gè)對(duì)象都是一個(gè)自治單位，不同對(duì)象之間是平級(jí)的，沒有主次、從屬、層次、分解等關(guān)系。抽象規(guī)格【對(duì)象部件】：自治的對(duì)象?！痉椒ㄕ{(diào)用

11、連接件】：典型的方法調(diào)用機(jī)制。管道過濾器風(fēng)格描述管道-過濾器風(fēng)格將系統(tǒng)的功能邏輯建立為部件集合。每個(gè)部件實(shí)例完成一個(gè)對(duì)數(shù)據(jù)流的獨(dú)立功能處理，它接收數(shù)據(jù)流輸入，進(jìn)行轉(zhuǎn)換和增量后進(jìn)行數(shù)據(jù)流輸出。連接件是管道機(jī)制，它將前一個(gè)過濾器的數(shù)據(jù)流輸出傳遞給后一個(gè)過濾器作為數(shù)據(jù)流輸入。連接件也可能會(huì)進(jìn)行數(shù)據(jù)流的功能處理，進(jìn)行轉(zhuǎn)換或增量，但連接件進(jìn)行功能處理的目的為了適配前一個(gè)過濾器的輸出和后一個(gè)過濾器的輸入，而不是為了直接承載軟件系統(tǒng)的需求。管道-過濾器風(fēng)格最重要的設(shè)計(jì)決策與約束是保證過濾器的獨(dú)立性，即：每個(gè)過濾器都獨(dú)立工作，無需知道通過管道與其相連的其他過濾器的特征。也就是說，每個(gè)過濾器只需要了解輸入數(shù)據(jù)流

12、和保證輸出數(shù)據(jù)流即可，不用關(guān)心一起工作的其他過濾器的實(shí)現(xiàn)細(xì)節(jié)。過濾器之間不能共享任何狀態(tài)，更不能共享數(shù)據(jù)。整個(gè)過濾網(wǎng)絡(luò)的正確輸出不能依賴于各過濾器的執(zhí)行順序。各個(gè)過濾器可以并發(fā)執(zhí)行。每個(gè)過濾器都可以在數(shù)據(jù)輸入不完備的情況下就開始進(jìn)行處理，每次接到一部分?jǐn)?shù)據(jù)流輸入就處理和產(chǎn)生一部分輸出。這樣，整個(gè)的過濾器網(wǎng)絡(luò)就形成了一條流水線。抽象規(guī)格【過濾器部件】：對(duì)數(shù)據(jù)流進(jìn)行轉(zhuǎn)換或增量的功能處理部件?！竟艿肋B接件】：傳遞數(shù)據(jù)流的連接件。隱式調(diào)用風(fēng)格描述隱式調(diào)用風(fēng)格將系統(tǒng)中的不同功能部分建立為部件，并使用事件（而不是程序調(diào)用）來實(shí)現(xiàn)不同部件之間的連接，也就是說隱式調(diào)用風(fēng)格使用事件傳播機(jī)制事件路由，來建立連接件

13、。隱式調(diào)用風(fēng)格中的行為者仍然會(huì)聲明可調(diào)用程序來提供對(duì)外的服務(wù)，但是這些程序卻不會(huì)直接被外界調(diào)用。隱式調(diào)用風(fēng)格采用的機(jī)制是將特定的事件類型與行為者的程序聯(lián)系起來，在相應(yīng)事件發(fā)生后，通過聯(lián)系可以找到需要調(diào)用的程序并將其調(diào)用執(zhí)行，這就是該風(fēng)格被稱為“隱式調(diào)用”的原因。對(duì)可調(diào)用程序接口的管理及其與事件類型的匹配都是連接件的工作。隱式調(diào)用風(fēng)格的重要設(shè)計(jì)決策與約束有：如果部件A和部件B需要相互協(xié)作，實(shí)現(xiàn)A調(diào)用B的效果，那么隱式調(diào)用風(fēng)格的協(xié)作機(jī)制為：（1）部件A向部件路由R聲明它將要拋出的事件類型e；（2）部件B在事件路由R中注冊(cè)“事件-程序”的映射關(guān)系，表明如果發(fā)生事件e，事件路由R可以調(diào)用B的程序p；（

14、3）在部件A需要與部件B協(xié)作時(shí)，部件A向事件路由廣播事件e；（4）事件路由根據(jù)注冊(cè)的映射關(guān)系，將部件B的程序p調(diào)入執(zhí)行。多個(gè)部件可以聲明同一個(gè)事件類型，每一個(gè)部件的事件廣播都有相同的調(diào)用效果。多個(gè)部件可以注冊(cè)同一個(gè)事件類型，并在事件發(fā)生后同時(shí)被調(diào)用執(zhí)行；事件的廣播者不知道哪些部件會(huì)受到影響，不能假設(shè)事件對(duì)部件的影響關(guān)系，甚至不能假設(shè)事件一定會(huì)有接收者。部件不能假設(shè)對(duì)事件的處理順序，也不能假設(shè)對(duì)事件的處理結(jié)果。抽象規(guī)格【Agent部件】：需要利用隱式調(diào)用機(jī)制實(shí)現(xiàn)協(xié)作的部件。declaration端口含有需求接口，描述了對(duì)事件聲明服務(wù)的期望，事件生命服務(wù)允許部件聲明自己將要廣播的事件類型。regi

15、ster端口含有需求接口，描述了對(duì)事件注冊(cè)服務(wù)的期望，時(shí)間注冊(cè)服務(wù)允許部件注冊(cè)自己感興趣的事件類型。端口announce含有需求接口，描述了對(duì)事件廣播服務(wù)的期望，事件廣播服務(wù)允許部件將一個(gè)事件廣播出去。端口calledProcedure含有供給接口，描述了相關(guān)聯(lián)事件發(fā)生后將會(huì)執(zhí)行的部件服務(wù)。【事件路由連接件】：角色publisher描述了EventRouter為事件聲明者提供的交互協(xié)議。角色subscriber描述了EventRouter為事件注冊(cè)者提供的交互協(xié)議。角色announcer描述了EventRouter為事件廣播者提供的交互協(xié)議。角色listener描述了EventRouter對(duì)事

16、件接收者的行為期望。在隱式調(diào)用風(fēng)格中，部件實(shí)例對(duì)交互的參與只依賴于事件類型，不受接口規(guī)格的影響。存儲(chǔ)庫(kù)風(fēng)格描述存儲(chǔ)庫(kù)風(fēng)格將系統(tǒng)的功能處理建立為一系列的知識(shí)源部件，它們收集和處理系統(tǒng)的數(shù)據(jù)信息，完成系統(tǒng)的功能任務(wù)。存儲(chǔ)庫(kù)風(fēng)格還建立了一個(gè)共享數(shù)據(jù)部件，它儲(chǔ)存系統(tǒng)所有的數(shù)據(jù)信息，代表了系統(tǒng)的狀態(tài)。知識(shí)源部件并不儲(chǔ)存數(shù)據(jù)，所以在它們進(jìn)行數(shù)據(jù)收集與處理時(shí)，需要訪問共享數(shù)據(jù)區(qū)，這是通過直接進(jìn)行存儲(chǔ)區(qū)訪問實(shí)現(xiàn)的，存儲(chǔ)庫(kù)風(fēng)格將對(duì)存儲(chǔ)區(qū)的直接訪問建立為連接件。存儲(chǔ)庫(kù)風(fēng)格的重要設(shè)計(jì)決策與約束有：所有的知識(shí)源相互獨(dú)立，它們彼此不互相調(diào)用，它們的活動(dòng)也沒有預(yù)先確定順序。所有的知識(shí)源都依賴于共享數(shù)據(jù)，不僅它們處理的數(shù)據(jù)

17、來自于共享數(shù)據(jù)，而且它們的執(zhí)行流程和順序也要取決于共享數(shù)據(jù)的狀態(tài)。知識(shí)源負(fù)責(zé)實(shí)時(shí)檢查共享數(shù)據(jù)的狀態(tài)，并在必要時(shí)做出合理的反應(yīng)。抽象規(guī)格【知識(shí)源部件】：收集和處理系統(tǒng)信息，完成系統(tǒng)功能任務(wù)的部件。端口accessData包含需求接口，描述了它期望外界所能提供的數(shù)據(jù)訪問交互?！竟蚕頂?shù)據(jù)部件】：儲(chǔ)存系統(tǒng)所有數(shù)據(jù)信息的部件。端口user包含供給接口，定義了它對(duì)外提供的數(shù)據(jù)訪問交互?！緝?nèi)存訪問連接件】：典型的存儲(chǔ)器訪問機(jī)制。角色accessor定義了給訪問者提供的交互行為。角色memory定義了對(duì)存儲(chǔ)器的交互行為期望。人們經(jīng)常將交互分為“拉（pull）”和“推（push）”兩種模式，它們都是站在交互發(fā)起

18、者的立場(chǎng)來描述的。“拉”（類似于拉的動(dòng)作）是指交互發(fā)起者主動(dòng)從外界查詢和獲得信息給自己，然后自行決定下一步行動(dòng)。而“推”（類似于推的動(dòng)作）則是指交互發(fā)起者將自己的信息告知給外界，由外界決定下一步行動(dòng)。存儲(chǔ)庫(kù)風(fēng)格采用的是“拉”模式，由知識(shí)源主動(dòng)發(fā)起查詢，并根據(jù)共享數(shù)據(jù)狀態(tài)決定下一步行動(dòng)。如果將知識(shí)源與共享數(shù)據(jù)的交互變?yōu)椤巴疲╬ush）”模式，由共享數(shù)據(jù)監(jiān)控狀態(tài)的變化，并在需要時(shí)通知知識(shí)源，然后再由知識(shí)源決定下一步行動(dòng)，那么這種變體形式就是黑板風(fēng)格（Blackboard Style）。因?yàn)橐O(jiān)控狀態(tài)變化，所以黑板風(fēng)格需要強(qiáng)化共享數(shù)據(jù)部件的控制功能，或者在共享數(shù)據(jù)部件之外，再建立一個(gè)控制部件。假設(shè)黑

19、板風(fēng)格除共享數(shù)據(jù)部件之外又建立了一個(gè)控制部件，那么它就擁有了三種部件類型（知識(shí)源、共享數(shù)據(jù)、控制）和3種連接件類型（數(shù)據(jù)訪問：連接知識(shí)源與共享數(shù)據(jù)；監(jiān)控：連接共享數(shù)據(jù)與控制；事件通知：連接控制與數(shù)據(jù)源），其交互機(jī)制為：（1） 知識(shí)源部件A首先在控制部件中注冊(cè)感興趣的數(shù)據(jù)及其狀態(tài)條件；（2） 控制部件持續(xù)監(jiān)控被注冊(cè)了興趣的數(shù)據(jù)及其狀態(tài)條件；（3） 另一個(gè)知識(shí)源部件B對(duì)共享數(shù)據(jù)的修改使得被注冊(cè)了興趣的數(shù)據(jù)滿足了狀態(tài)條件；（4） 控制部件廣播事件，通知所有注冊(cè)了相應(yīng)數(shù)據(jù)及其狀態(tài)條件的知識(shí)源；（5） 知識(shí)源A接收到事件，進(jìn)行功能處理。因?yàn)楹诎屣L(fēng)格對(duì)共享數(shù)據(jù)進(jìn)行了全局性的控制，所以它能夠更好地解決模糊性

20、與不確定性問題。實(shí)際應(yīng)用中，專家系統(tǒng)、集成開發(fā)環(huán)境、聊天室等都采用了黑板風(fēng)格。存儲(chǔ)庫(kù)風(fēng)格與黑板風(fēng)格的比較存儲(chǔ)庫(kù)風(fēng)格使用“拉”模型：組件向存儲(chǔ)庫(kù)中寫數(shù)據(jù)組件從存儲(chǔ)庫(kù)中讀數(shù)據(jù)容易實(shí)現(xiàn)客戶端復(fù)雜，且必須回滾數(shù)據(jù)黑板風(fēng)格使用“推”模型：組件注冊(cè)訂閱數(shù)據(jù)數(shù)據(jù)可獲取是組件被通知客戶端程序簡(jiǎn)單需要復(fù)雜的基礎(chǔ)分層風(fēng)格描述分層風(fēng)格根據(jù)不同的抽象層次，將系統(tǒng)組織為層次式結(jié)構(gòu)。每個(gè)層次被建立為一個(gè)部件，不同部件之間通常用程序調(diào)用方式進(jìn)行連接，因此連接件被建立為程序調(diào)用機(jī)制。分層風(fēng)格的重要設(shè)計(jì)決策與約束有：從最底層到最高層，部件的抽象層次逐漸提升。每個(gè)下層為鄰接上層提供服務(wù)，每個(gè)上層將鄰接下層作為基礎(chǔ)設(shè)施使用。也就是

21、說，在程序調(diào)用機(jī)制中上層調(diào)用下層。兩個(gè)層次之間的連接要遵守特定的交互協(xié)議，該交互協(xié)議應(yīng)該是成熟、穩(wěn)定和標(biāo)準(zhǔn)化的。也就是說，只要遵守交互協(xié)議，不同部件實(shí)例之間是可以互相替換的。跨層次的連接是禁止的，不允許第I層直接調(diào)用I+N（N1）層的服務(wù)。逆向的連接是禁止的，不允許第I層調(diào)用第J（JI）層的服務(wù)。抽象規(guī)格【層次部件】：service端口為上層部件提供服務(wù)，包含供給接口，infrastructure端口對(duì)下層部件提供服務(wù)期望，包含需求接口。【程序調(diào)用】：遵守特定交互協(xié)議的程序調(diào)用機(jī)制。支持并發(fā)。進(jìn)程層次的設(shè)計(jì)風(fēng)格點(diǎn)對(duì)點(diǎn)風(fēng)格分布式系統(tǒng)中的同步消息傳遞機(jī)制。松耦合，組件相互獨(dú)立。發(fā)布訂閱風(fēng)格 多個(gè)應(yīng)

22、用希望接收相同的消息（廣播）。發(fā)布者和訂閱者是解耦的消息傳遞是基于事件訂閱的物理單元層次的設(shè)計(jì)風(fēng)格客戶端服務(wù)器風(fēng)格描述客戶端/服務(wù)器風(fēng)格將系統(tǒng)的功能進(jìn)行了劃分。劃分后的一部分功能被建立為服務(wù)器部件，它們通常有較高的資源要求。系統(tǒng)中另一部分功能被建立為客戶端部件，它們需要處理更多的用戶交互。網(wǎng)絡(luò)連接被建立為連接件，它將客戶端的請(qǐng)求發(fā)送到服務(wù)器，服務(wù)器提供服務(wù)滿足請(qǐng)求，網(wǎng)絡(luò)連接再將服務(wù)的結(jié)果返還回客戶端。客戶端/服務(wù)器風(fēng)格的重要設(shè)計(jì)決策與約束有：服務(wù)器較為固定，每個(gè)客戶端都知道服務(wù)器的標(biāo)識(shí)；客戶端可以動(dòng)態(tài)增減，服務(wù)器不知道客戶端的標(biāo)識(shí)；各個(gè)客戶端之間相互獨(dú)立，它們都依賴于服務(wù)器。抽象規(guī)格【客戶端部

23、件】：主要承載用戶交互功能的部件。【服務(wù)器部件】：承載復(fù)雜功能的部件。【網(wǎng)絡(luò)連接連接件】：典型的網(wǎng)絡(luò)連接機(jī)制。變化形式三層風(fēng)格依據(jù)客戶端和服務(wù)器分擔(dān)職責(zé)的不同，客戶端/服務(wù)器風(fēng)格可以分為“瘦（Thin）”客戶端和“胖（Fat）”客戶端兩種類型?！笆荩═hin）”客戶端類型將更多的功能部署到服務(wù)器上，減輕客戶端負(fù)擔(dān)的同時(shí)，也加重了服務(wù)器的負(fù)載，使得服務(wù)器的瓶頸缺點(diǎn)越發(fā)明顯。B/S風(fēng)格就是典型的“瘦（Thin）”客戶端類型?！芭帧笨蛻舳祟愋蛯⒏嗟墓δ懿渴鸬娇蛻舳松?，以減輕服務(wù)器的壓力。但是客戶端功能過多又會(huì)增加系統(tǒng)的網(wǎng)絡(luò)通信復(fù)雜度，使得系統(tǒng)開發(fā)更加困難，同時(shí)修改之后的程序更新工作也會(huì)更加繁雜。為

24、了解決“瘦”與“胖”之間的兩難選擇，人們提出了一種客戶端/服務(wù)器風(fēng)格的變體形式三層（3-Tier）。三層風(fēng)格在客戶端與服務(wù)器之間加入一個(gè)新的層次業(yè)務(wù)邏輯層，如圖三層風(fēng)格分為三個(gè)層次：表現(xiàn)層類似于C/S的瘦客戶端，主要負(fù)責(zé)業(yè)務(wù)表現(xiàn)和用戶交互，部署在網(wǎng)絡(luò)中眾多用戶使用的物理單元上。業(yè)務(wù)邏輯層負(fù)責(zé)系統(tǒng)的功能邏輯，完成系統(tǒng)任務(wù)，部署在網(wǎng)絡(luò)中的業(yè)務(wù)邏輯服務(wù)器節(jié)點(diǎn)。表現(xiàn)層與業(yè)務(wù)邏輯層是C/S關(guān)系，表現(xiàn)層為Client，業(yè)務(wù)邏輯層為Server。數(shù)據(jù)服務(wù)層負(fù)責(zé)系統(tǒng)的數(shù)據(jù)服務(wù)，部署在網(wǎng)絡(luò)中的數(shù)據(jù)服務(wù)器節(jié)點(diǎn)。業(yè)務(wù)邏輯層與數(shù)據(jù)服務(wù)層是C/S關(guān)系，業(yè)務(wù)邏輯層為Client，數(shù)據(jù)服務(wù)層為Server。按照同樣的道理，

25、業(yè)務(wù)邏輯層也可以進(jìn)行分解，分為多層部署，以減輕每一層的服務(wù)器負(fù)載，此時(shí)該變體稱為N層（N-Tier）風(fēng)格。最后需要強(qiáng)調(diào)的是，這里的“層”與分層風(fēng)格的“層”是不同的概念，分層風(fēng)格的“層”英文為L(zhǎng)ayer，是模塊的組織，三層的“層”英文為“Tier”，是網(wǎng)絡(luò)部署的組織。端到端風(fēng)格前面所述的C/S風(fēng)格及其變體形式都明確區(qū)分了客戶端和服務(wù)器，主要的功能都由服務(wù)器來承擔(dān)。但是，有些系統(tǒng)的功能負(fù)載非常高，很難由一個(gè)或幾個(gè)服務(wù)器來承擔(dān)。因此，又產(chǎn)生了一種類似于分布式系統(tǒng)風(fēng)格的端到端（Peer to Peer）風(fēng)格。在端到端風(fēng)格中，每個(gè)參與者都既是客戶端，又是服務(wù)器分布式系統(tǒng)chapter 理解軟件體系結(jié)構(gòu)軟

26、件體系結(jié)構(gòu)的三個(gè)方面：高層次結(jié)構(gòu)、關(guān)注點(diǎn)、設(shè)計(jì)決策詳細(xì)設(shè)計(jì)機(jī)制的不足關(guān)注點(diǎn)偏差（載體失配）作為載體，程序語(yǔ)言可以描述數(shù)據(jù)結(jié)構(gòu)+算法，以及由此衍生的模塊、類等結(jié)構(gòu)，能夠描述功能邏輯，但無法描述可靠性、性能等整體結(jié)構(gòu)的質(zhì)量要求 根據(jù)最初的設(shè)計(jì)，程序設(shè)計(jì)語(yǔ)言不承載質(zhì)量要求 無法實(shí)現(xiàn)交互信息本地化（信息隱藏局限性）單詞匹配的需求使得模塊間必須依賴于對(duì)方的接口，導(dǎo)致信息隱藏的局限性 模塊間復(fù)雜連接邏輯被分散到其內(nèi)部類之間，既突破了”NO INSIDE”的限制，又使得理解變得困難無法有效抽象部件的整體特性（無法描述module自身）總是進(jìn)行模塊內(nèi)部的描述接口聯(lián)合起來能夠表現(xiàn)module的功能，但無法表現(xiàn)一

27、個(gè)module的質(zhì)量特性接口的定義缺乏結(jié)構(gòu)性模塊的眾多接口之間太獨(dú)立無法實(shí)現(xiàn)區(qū)別對(duì)待：為不同的其他模塊公開不同的接口，尤其是不同的質(zhì)量要求不能有效適應(yīng)大型軟件的特殊開發(fā)方法復(fù)用與單次匹配多語(yǔ)言/多范型與聯(lián)合編譯遺留資產(chǎn)與module inside使用高層次結(jié)構(gòu)的特點(diǎn)部件+連接件+配置模塊本身包含質(zhì)量屬性（部件）模塊之間的交互由一個(gè)獨(dú)立的組件完成（連接件）部件和連接件通過配置進(jìn)行關(guān)聯(lián)高層次結(jié)構(gòu)理解軟件體系結(jié)構(gòu)的三個(gè)方面之一部件關(guān)注處理和數(shù)據(jù)；連接件關(guān)注部件之間的交互。連接件單獨(dú)作為一個(gè)組件被考慮的原因：The definition of a connector should be localiz

28、ed連接件可能非常的復(fù)雜。系統(tǒng)中的交互信息很難放在某個(gè)部件中所有的元素都應(yīng)該被獨(dú)立出來【部件】軟件體系結(jié)構(gòu)中封裝處理和數(shù)據(jù)的組件。部件包括抽象規(guī)格與具體實(shí)現(xiàn)兩個(gè)部分。抽象規(guī)格：包括端口和特征集。特征集：包括部件的類型、功能性、約束、質(zhì)量屬性等特征。端口：對(duì)外可見、可被外界引用的接口實(shí)體，代表了部件對(duì)外承諾的一種職責(zé)。部件可分為兩種類型：原始部件和復(fù)合部件。原始部件可以直接被實(shí)現(xiàn)為響應(yīng)的軟件實(shí)現(xiàn)機(jī)制。軟件實(shí)現(xiàn)機(jī)制 示例 模塊(Module) Routine, SubRoutine 層(Layer) View, Logical, Model 文件(File) DLL, EXE, DAT 數(shù)據(jù)庫(kù)(D

29、atabase) Repository, Center Data 進(jìn)程(Process) Sender, Receiver 網(wǎng)絡(luò)節(jié)點(diǎn)(Physical Unit) Client, Server 復(fù)合部件由更細(xì)粒度的部件和連接件組成，復(fù)合部件通過局部配置將其內(nèi)部的部件和連接件連接起來，構(gòu)成一個(gè)整體?！具B接件】連接件是軟件體系結(jié)構(gòu)中承載部件之間交互的中介，連接件并不直接關(guān)聯(lián)到部件，這個(gè)工作將由配置來完成。連接件包括抽象規(guī)格與具體實(shí)現(xiàn)兩個(gè)部分。抽象規(guī)格：包括角色和特征集。特征集：包括類型、接口規(guī)則、交互斷言、交互協(xié)議等。角色：對(duì)外可見、可被外界引用的接口實(shí)體，每個(gè)角色代表一個(gè)交互參與方需要滿足的一些

30、條件，基本的條件是匹配該角色的端口所應(yīng)復(fù)合的規(guī)則，復(fù)雜的條件可能會(huì)包括加密通信、負(fù)載均衡等?！九渲谩坎考瓦B接件都是軟件體系結(jié)構(gòu)獨(dú)立的元素，相互之間沒有直接的關(guān)聯(lián)，配置是將部件和連接件整合起來的專門的機(jī)制。配置通過部件端口與連接件角色相匹配的方式，將系統(tǒng)中部件和連接件的關(guān)系定義為一個(gè)關(guān)聯(lián)集合，這個(gè)關(guān)聯(lián)集合可以形成系統(tǒng)整體結(jié)構(gòu)的一個(gè)拓?fù)涿枋?。利用配置將相互?dú)立的部件和連接件聯(lián)系起來，而不是之直接指定部件與連接件的關(guān)系的好處：可以實(shí)現(xiàn)部件和連接件的一次定義，多處使用在具體交互中，參與的部件不在固定，可以隨時(shí)發(fā)生變化對(duì)具體部件而言，其所參與的交互也不在固定，部件隨時(shí)可以參與或退出一個(gè)交互關(guān)注點(diǎn)理解軟

31、件體系結(jié)構(gòu)的三個(gè)方面之二質(zhì)量屬性是影響軟件系統(tǒng)復(fù)雜度的關(guān)鍵因素，軟件體系結(jié)構(gòu)是處理質(zhì)量屬性和控制復(fù)雜度的主要手段，質(zhì)量屬性是軟件體系結(jié)構(gòu)最為重要的關(guān)注點(diǎn)。軟件體系結(jié)構(gòu)的主要關(guān)注點(diǎn)：系統(tǒng)質(zhì)量，項(xiàng)目環(huán)境，商業(yè)目標(biāo)設(shè)計(jì)決策理解軟件體系結(jié)構(gòu)的三個(gè)方面之三軟件體系結(jié)構(gòu)需要表現(xiàn)關(guān)注點(diǎn)，關(guān)注點(diǎn)對(duì)軟件體系結(jié)構(gòu)的最終的樣式有著重要的影響，但是關(guān)注點(diǎn)并不能直接的反映為軟件體系結(jié)構(gòu)的高層結(jié)構(gòu)元素，關(guān)注點(diǎn)與高層結(jié)構(gòu)之間存在差距，關(guān)注點(diǎn)必須通過設(shè)計(jì)決策才能轉(zhuǎn)化到高層結(jié)構(gòu)上。軟件體系結(jié)構(gòu)是重要設(shè)計(jì)決策的集合。設(shè)計(jì)決策的定義：設(shè)計(jì)決策對(duì)元素、特征和處理的選擇，它們涉及一個(gè)或多個(gè)關(guān)注點(diǎn)，直接或間接的影響到軟件體系結(jié)構(gòu)。設(shè)計(jì)決

32、策的核心知識(shí)可以分為四個(gè)部分：關(guān)注點(diǎn)、解決方案、策略和理由。chapter 4+1 View邏輯視圖：關(guān)注系統(tǒng)的邏輯結(jié)構(gòu)和重要的設(shè)計(jì)機(jī)制，描述系統(tǒng)提供的功能和服務(wù)。開發(fā)視圖：關(guān)注系統(tǒng)的實(shí)現(xiàn)結(jié)構(gòu)，描述系統(tǒng)開發(fā)的組織。進(jìn)程視圖：關(guān)注系統(tǒng)的運(yùn)行時(shí)表現(xiàn)，描述系統(tǒng)的并發(fā)進(jìn)程組織。物理視圖：關(guān)注系統(tǒng)的基礎(chǔ)設(shè)施，描述系統(tǒng)的部署與分布。場(chǎng)景視圖：關(guān)注系統(tǒng)最為重要的需求，描述系統(tǒng)應(yīng)該實(shí)現(xiàn)的場(chǎng)景與用例。場(chǎng)景視圖（用例視圖）用例視圖關(guān)注的是軟件體系結(jié)構(gòu)的需求，它們一方面說明軟件體系結(jié)構(gòu)設(shè)計(jì)的出發(fā)點(diǎn)，驅(qū)動(dòng)其他4個(gè)視圖的設(shè)計(jì)；另一方面用于驗(yàn)證和評(píng)估其他4個(gè)視圖的設(shè)計(jì)，保證它們的正確性。用例視圖只是描述了軟件體系結(jié)構(gòu)的需

33、求，并不涉及軟件體系結(jié)構(gòu)的抽象規(guī)格，也不涉及軟件體系結(jié)構(gòu)的實(shí)現(xiàn)，所以與其他4個(gè)視圖不同的是，它沒有直接貢獻(xiàn)于軟件體系結(jié)構(gòu)自身的描述，以至于被稱為“+1”。用例視圖中的用例既包括【功能需求用例】，還包括軟件體系結(jié)構(gòu)關(guān)注點(diǎn)【質(zhì)量屬性】和【項(xiàng)目環(huán)境】的用例。邏輯視圖用戶角度考慮邏輯視圖描述的是一個(gè)滿足了需求的軟件體系結(jié)構(gòu)設(shè)計(jì)，其主要內(nèi)容是軟件體系結(jié)構(gòu)的抽象規(guī)格，主要關(guān)注點(diǎn)是滿足用戶的各項(xiàng)需求，尤其是功能需求、質(zhì)量屬性需求和約束。也就是說，邏輯視圖從總體功能組織的角度來描述軟件系統(tǒng)的高層結(jié)構(gòu)，說明用戶需求在軟件體系結(jié)構(gòu)元素中的分解與分配，解釋軟件系統(tǒng)保證需求實(shí)現(xiàn)的設(shè)計(jì)機(jī)制。邏輯視圖的內(nèi)容是軟件體系結(jié)構(gòu)

34、的抽象規(guī)格，其主要結(jié)構(gòu)實(shí)體為部件、連接件、端口、角色、特征、配置等。但是在描述復(fù)雜軟件系統(tǒng)時(shí)，可能還需要詳細(xì)描述部件與連接件的功能規(guī)格和交互協(xié)議。以對(duì)基本結(jié)構(gòu)元素的擴(kuò)展為基礎(chǔ)，可以用下列機(jī)制來實(shí)現(xiàn)：為部件類型建立行為狀態(tài)圖，描述部件類型的詳細(xì)功能規(guī)格；為連接件類型建立行為狀態(tài)圖，描述連接件類型的交互機(jī)制；為端口建立協(xié)議狀態(tài)機(jī)，描述部件端口和連接件角色的交互協(xié)議；為配置和復(fù)合類型建立順序圖，描述配置和復(fù)合類型所包含的功能規(guī)格。開發(fā)視圖開發(fā)者角度考慮開發(fā)視圖關(guān)注軟件體系結(jié)構(gòu)的模塊實(shí)現(xiàn)，體現(xiàn)軟件系統(tǒng)的模塊組織。因此，軟件體系結(jié)構(gòu)的實(shí)現(xiàn)既要能夠合理劃分，建立模塊化程度較好的模塊集，以利于各個(gè)模塊的獨(dú)立

35、開發(fā)與復(fù)用，又要能夠?qū)⒒A(chǔ)模塊集組織成層、子系統(tǒng)等層次結(jié)構(gòu)，以輔助項(xiàng)目管理活動(dòng)的開展。在邏輯視圖的基礎(chǔ)上，強(qiáng)調(diào)使用模塊化和信息隱藏的思想劃分出易于開發(fā)實(shí)現(xiàn)的模塊。每個(gè)模塊對(duì)外存在需求或供給接口。進(jìn)程視圖集成開發(fā)者角度考慮進(jìn)程視圖關(guān)注軟件體系結(jié)構(gòu)的運(yùn)行時(shí)表現(xiàn)，考慮在靜態(tài)結(jié)構(gòu)中難以分析的性能、可靠性等非功能需求，也會(huì)描述為保障系統(tǒng)完整性和容錯(cuò)性而需要的進(jìn)程并發(fā)及其分布，還要說明軟件體系結(jié)構(gòu)的抽象規(guī)格是如何被進(jìn)程實(shí)現(xiàn)的可執(zhí)行的進(jìn)程、線程及其負(fù)責(zé)的操作與控制邏輯。軟件系統(tǒng)的功能可以劃分為一系列相對(duì)獨(dú)立的任務(wù)。在任務(wù)內(nèi)部，實(shí)現(xiàn)元素之間的聯(lián)系比較頻繁，結(jié)合比較緊密。但是在任務(wù)之間，雙方的實(shí)現(xiàn)元素之間只保持

36、較少的連接，相對(duì)比較獨(dú)立。因此，不同任務(wù)可能會(huì)被實(shí)現(xiàn)為不同的可執(zhí)行單元進(jìn)程或者線程，這種分割實(shí)現(xiàn)的方式可以幫助降低軟件系統(tǒng)的實(shí)現(xiàn)復(fù)雜度，所以在復(fù)雜的軟件系統(tǒng)開發(fā)中是一種重要的設(shè)計(jì)機(jī)制。進(jìn)程就是由任務(wù)組形成的一個(gè)可執(zhí)行單元，它是軟件體系結(jié)構(gòu)進(jìn)程實(shí)現(xiàn)的基礎(chǔ)元素。進(jìn)程的并發(fā)與分布情況可以體現(xiàn)軟件體系結(jié)構(gòu)對(duì)性能和可靠性的處理機(jī)制。部署視圖系統(tǒng)工程師角度考慮將軟件映射到硬件上部署視圖關(guān)注可靠性、容錯(cuò)性、吞吐量、容量等與基礎(chǔ)設(shè)施相關(guān)的非功能需求（例如，雙機(jī)熱備份系統(tǒng)的可靠性要高于單機(jī)系統(tǒng)，多機(jī)之間互相校驗(yàn)的系統(tǒng)要具有更高的容錯(cuò)性），描述軟件體系結(jié)構(gòu)的基礎(chǔ)設(shè)施和網(wǎng)絡(luò)分布，明確任務(wù)、進(jìn)程、構(gòu)件、重要制品（Ar

37、tifact）以及環(huán)境的部署與分布。chapter 體系結(jié)構(gòu)設(shè)計(jì)體系結(jié)構(gòu)設(shè)計(jì)的考慮方面結(jié)構(gòu)高層結(jié)構(gòu)多視圖結(jié)構(gòu)（4+1 View）關(guān)注點(diǎn)質(zhì)量屬性項(xiàng)目環(huán)境商業(yè)目標(biāo)設(shè)計(jì)決策關(guān)注點(diǎn)產(chǎn)生的問題因素的解決方案風(fēng)格一組設(shè)計(jì)決策形成的風(fēng)格體系結(jié)構(gòu)設(shè)計(jì)的步驟體系結(jié)構(gòu)分析體系結(jié)構(gòu)需求分析功能需求關(guān)注點(diǎn)質(zhì)量屬性項(xiàng)目環(huán)境商業(yè)目標(biāo)定義體系結(jié)構(gòu)需求定義需求的場(chǎng)景描述定義初始體系結(jié)構(gòu)利用4+1 view表示建立體系結(jié)構(gòu)確定設(shè)計(jì)決策，修正體系結(jié)構(gòu)chapter 設(shè)計(jì)模式面向接口編程通過模塊的名字與整個(gè)模塊建立的聯(lián)系產(chǎn)生的耦合 與模塊內(nèi)部元素產(chǎn)生的耦合。普通面向接口編程的手段封裝繼承集合類型中實(shí)現(xiàn)面向接口編程的手段迭代器模式為

38、遍歷不同類型的集合提供統(tǒng)一的接口，隱藏了集合類型數(shù)據(jù)結(jié)構(gòu)的內(nèi)部結(jié)構(gòu)信息。體現(xiàn)了【面向接口編程】【信息隱藏】的思想。集合類型的內(nèi)部結(jié)構(gòu)是可變的，不影響迭代器對(duì)外的接口。迭代器對(duì)外的接口是可拓展的，可以隨意添加集合類型的遍歷方式。代理模式為其他對(duì)象提供了一種代理，來控制對(duì)目標(biāo)對(duì)象的訪問，通過代理實(shí)現(xiàn)間接的訪問。原型模式？【集合類型中實(shí)現(xiàn)面向接口編程的手段？】解耦的手段避免重復(fù)：重復(fù)的出現(xiàn)會(huì)導(dǎo)致一個(gè)地方的修改引發(fā)另一個(gè)地方也需要修改。DIP 依賴倒置原則：高層模塊不應(yīng)該依賴于底層模塊的實(shí)現(xiàn)，而是依賴于高層抽象。抽象不應(yīng)該依賴與具體實(shí)現(xiàn)，具體實(shí)現(xiàn)應(yīng)該依賴于抽象。間接訪問：代理模式協(xié)作設(shè)計(jì)：中介者模式橋

39、接模式中介者模式問題：一組對(duì)象的交互遵從同一規(guī)則，但是十分復(fù)雜。中介者模式將對(duì)象之間的交互封裝起來，通過減少對(duì)象與對(duì)象之間的引用來解耦。使得對(duì)象之間的交互可以獨(dú)立變化?！炯惺娇刂骑L(fēng)格】橋接模式將接口與實(shí)現(xiàn)分離，提高了可拓展性，對(duì)客戶端隱藏實(shí)現(xiàn)。信息隱藏每個(gè)模塊都擁有一個(gè)基本的秘密：外部行為和內(nèi)部實(shí)現(xiàn)。每個(gè)模塊都隱藏了一個(gè)重要設(shè)計(jì)決策的實(shí)現(xiàn)，所以只有模塊自身知道實(shí)現(xiàn)細(xì)節(jié)。每個(gè)模塊可能擁有一個(gè)額外的秘密：變化或修改。一個(gè)模塊信息隱藏的兩種基本手段信息隱藏的兩種基本類型：（隱藏設(shè)計(jì)決策、隱藏變化）外觀模式隱藏設(shè)計(jì)決策外觀模式提供了一個(gè)統(tǒng)一的接口，用來訪問子系統(tǒng)中的一群接口。它提供了一個(gè)高層接口，讓

40、子系統(tǒng)更容易的使用，隱藏了內(nèi)部實(shí)現(xiàn)。實(shí)現(xiàn)了客戶端與子系統(tǒng)之間的解耦。【外觀模式】與【協(xié)作設(shè)計(jì)】的異同：【外觀模式】可以作為集中式的控制器?！緟f(xié)作設(shè)計(jì)】封裝的是由多個(gè)對(duì)象協(xié)作完成的一個(gè)task?！就庥^模式】可以僅僅封裝關(guān)系緊密的對(duì)象，不一定是封裝形成一個(gè)task?！就庥^模式】與【中介者模式】在協(xié)作設(shè)計(jì)方面的異同：【外觀模式】封裝了關(guān)系緊密的幾個(gè)對(duì)象，提供一個(gè)高層次的接口，供外界進(jìn)行訪問，主要作用是對(duì)外提供服務(wù)?！局薪檎吣Ｊ健繉?duì)象之間的交互進(jìn)行封裝，并不對(duì)外提供服務(wù)。策略模式隱藏變化針對(duì)變化。實(shí)現(xiàn)了可修改性和可復(fù)用性共性和差異性繼承關(guān)系：共性放在父類中，差異性放在子類中，實(shí)現(xiàn)多選一的關(guān)系。聚合關(guān)

41、系：共性放在整體中，差異性放在部分中，實(shí)現(xiàn)多選多的關(guān)系。實(shí)現(xiàn)共性和可變性（差異性）的手段隱藏變化？策略模式狀態(tài)模式橋接模式OCP原則隱藏變化？對(duì)拓展開放，對(duì)修改封閉。對(duì)拓展開放：模塊的行為是可以拓展的對(duì)修改封閉：模塊的內(nèi)部實(shí)現(xiàn)的代碼是不可修改的裝飾者模式裝飾者模式動(dòng)態(tài)給一個(gè)對(duì)象添加一些額外的職責(zé)。 我們通常使用繼承來實(shí)現(xiàn)功能的拓展，但如果需要拓展的功能的種類繁多，那么會(huì)生成很多子類，從而增加了系統(tǒng)的復(fù)雜性。同時(shí)，使用繼承實(shí)現(xiàn)功能拓展，我們必須可預(yù)見這些拓展的功能，即功能在編譯時(shí)就是確定的，是靜態(tài)的。 使用裝飾者模式，功能的拓展可以由用戶動(dòng)態(tài)決定加入的方式和時(shí)機(jī)，在運(yùn)行期間決定何時(shí)增加何種功能，

42、相比使用生成子類方式達(dá)到功能的擴(kuò)充顯得更為靈活。適配器模式運(yùn)行時(shí)注冊(cè)觀察者模式命令模式對(duì)象創(chuàng)建單體模式工廠模式抽象工廠模式原型模式chapter 職責(zé)分配（GRASP模式）職責(zé)：職責(zé)是對(duì)象的功能，維護(hù)對(duì)象對(duì)外的協(xié)議和狀態(tài)。職責(zé)對(duì)設(shè)計(jì)的影響：?jiǎn)我宦氊?zé)原則：每個(gè)模塊只完成一個(gè)職責(zé)，實(shí)現(xiàn)一個(gè)功能。信息隱藏：每個(gè)模塊隱藏一個(gè)獨(dú)立的設(shè)計(jì)決策。module guide的來源：SRS和變化職責(zé)分配：把職責(zé)分配給體系結(jié)構(gòu)中的一個(gè)或多個(gè)類。GRASP模式專家模式問題：面向?qū)ο笤O(shè)計(jì)中職責(zé)分配最基本的原則是什么？【職責(zé)應(yīng)該分配給誰？】解決：把職責(zé)分配給擁有完成該職責(zé)所必須的信息的類。效果：維護(hù)信息的封裝降低耦合提高

43、內(nèi)聚會(huì)導(dǎo)致一個(gè)類過于復(fù)雜創(chuàng)建者模式問題：將創(chuàng)建對(duì)象的職責(zé)分配給誰？解決：在決定哪個(gè)類負(fù)責(zé)對(duì)象的創(chuàng)建時(shí)，考慮潛在的創(chuàng)建者類和被創(chuàng)建的類之間的關(guān)系。B負(fù)責(zé)創(chuàng)建A，如果：B由A聚合而成；B包含A；（B包含一個(gè)屬性為A）B中創(chuàng)建A供來使用；B包含創(chuàng)建A的初始化信息。效果：通過讓一個(gè)類負(fù)責(zé)創(chuàng)建它需要引用的對(duì)象，來降低耦合。自己使用，自己創(chuàng)建，可以不依賴與其他類為自己創(chuàng)建。低耦合模式問題：如何降低依賴，提高復(fù)用？解決：通過職責(zé)分配降低耦合。效果：變化的部分可以被鎖定。容易理解，容易復(fù)用。高內(nèi)聚模式問題：如何維護(hù)復(fù)雜的管理？解決：通過職責(zé)分配提高內(nèi)聚。效果：類易于維護(hù)，易于理解，通常支持低耦合，支持復(fù)用。控制者模式問題：處理系統(tǒng)外部事件的職責(zé)應(yīng)該如何分配？解決：如果系統(tǒng)從外部或圖形化界面接收事件，那么添加一個(gè)響應(yīng)事件的類來與處理事件的類解耦