體系結(jié)構(gòu)資料：復(fù)習(xí)提綱

1、名詞解釋：模塊化、信息隱藏、軟件體系結(jié)構(gòu)（三個(gè)不同方面）、4+1 View、GRASP模式（或其中之一）、設(shè)計(jì)模式、MVC模塊化：將程序分成小部分的工作集，即模塊，這些模塊可以一起組成完整的系統(tǒng)，是抽象和分解的過程。模塊被獨(dú)立對(duì)待；可獨(dú)立理解、使用或重用、構(gòu)建每個(gè)模塊；一個(gè)模塊失敗不會(huì)影響到其他模塊，更易隔離失效；一個(gè)模塊改變不影響其他模塊，限制了連鎖反應(yīng)。模塊化要達(dá)到模塊獨(dú)立設(shè)計(jì)、測(cè)試、改變、容易集成，從而減少整個(gè)軟件的成本。對(duì)程序的分解會(huì)增加復(fù)雜性，故產(chǎn)生了耦合和內(nèi)聚的方法。信息隱藏：每個(gè)模塊隱藏一個(gè)重要設(shè)計(jì)決策的實(shí)現(xiàn)即為這個(gè)模塊的Secret，只有那個(gè)模塊的組成部分知道細(xì)節(jié)；模塊的接口被

2、抽象精確的定義；可能改變的實(shí)現(xiàn)細(xì)節(jié)被抽象化，不能隱藏的可能改變的部分被參數(shù)化；通過被賦予其自己的類、子過程或設(shè)計(jì)單元，設(shè)計(jì)的secret被分開，從而達(dá)到一個(gè)secret變化其他不受影響的目的軟件體系結(jié)構(gòu)（三個(gè)不同方面）：從高層結(jié)構(gòu)、關(guān)注點(diǎn)和設(shè)計(jì)決策3個(gè)不同方面來理解體系結(jié)構(gòu)；從高層結(jié)構(gòu)方面理解，軟件體系結(jié)構(gòu)是部件、連接件和配置組成的，其中部件和連接件是核心的元素，而配置描述這兩者的適配情況，這一方面強(qiáng)調(diào)了其作為高層抽象的作用；從關(guān)注點(diǎn)方面來理解，軟件體系結(jié)構(gòu)包括需求（質(zhì)量屬性）、項(xiàng)目環(huán)境和商業(yè)目標(biāo)，這一方面體現(xiàn)了不同涉眾對(duì)于軟件體系結(jié)構(gòu)的要求，強(qiáng)調(diào)了其作為交流媒介的作用；從設(shè)計(jì)決策方面來理解，

3、軟件體系結(jié)構(gòu)需說明問題、候選設(shè)計(jì)、理由和解決方案，這是體系結(jié)構(gòu)形成的理由，強(qiáng)調(diào)了其指導(dǎo)開發(fā)的作用。4+1 View：IBM提出的一種multi-point的體系結(jié)構(gòu)模型，共有5個(gè)viewpoint，關(guān)注點(diǎn)在設(shè)計(jì)上，特別適用于迭代設(shè)計(jì)過程，由4個(gè)View（邏輯、開發(fā)、進(jìn)程和物理）以及1個(gè)特殊viewpoint場(chǎng)景來描述體系結(jié)構(gòu)，不同的涉眾可選取自己關(guān)系的view來理解。邏輯視圖為面向?qū)ο蟮姆纸?，由關(guān)鍵的抽象部件連接件以及配置組成，考慮功能需求，針對(duì)終端用戶；進(jìn)程視圖為進(jìn)程分解，有多個(gè)層次，包含一個(gè)進(jìn)程網(wǎng)絡(luò)，軟件分解為一組可執(zhí)行的工作單元，考慮非功能需求，針對(duì)集成人員；開發(fā)視圖為子系統(tǒng)分解，是產(chǎn)品

4、線的基礎(chǔ)，有模塊和子系統(tǒng)圖組成，考慮軟件模塊的組織層次、管理、重用以及工具，層次式風(fēng)格，針對(duì)編程人員和軟件管理者；物理視圖將軟件映射到硬件，包含網(wǎng)絡(luò)、task以及對(duì)象映射為節(jié)點(diǎn)時(shí)的拓?fù)浣Y(jié)構(gòu)和通信，考慮與硬件相關(guān)的肺功能呢個(gè)需求，針對(duì)系統(tǒng)工程師；場(chǎng)景將上面的視圖元素組織在一起，通過一小組重要的場(chǎng)景來表現(xiàn)各視圖的工作，考慮系統(tǒng)一致性和驗(yàn)證，針對(duì)其他視圖和評(píng)估者等所有用戶。MVC：可以說是一種體系結(jié)構(gòu)風(fēng)格，也可以說是一種設(shè)計(jì)模式。分為model、view和controller三種組件；model子系統(tǒng)設(shè)計(jì)為不依賴任何view子系統(tǒng)和controller子系統(tǒng)，其狀態(tài)的變化會(huì)傳遞給view子系統(tǒng)；mo

5、del組件負(fù)責(zé)維護(hù)領(lǐng)域知識(shí)和通知view變化，view組件負(fù)責(zé)顯示信息并傳遞用戶指示給controller，controller負(fù)責(zé)更改model狀態(tài)和選擇響應(yīng)view，連接件是過程調(diào)用、消息、事件、直接內(nèi)存存?。辉试S一個(gè)model上建立多個(gè)獨(dú)立view，view可同步，可“插拔”（易于修改）的view和controller，但增加了復(fù)雜性，view獲取數(shù)據(jù)效率不高，與流行UI工具不十分兼容，適用于UI修改容易并且可以運(yùn)行時(shí)修改、UI的修改不應(yīng)該影響功能部分設(shè)計(jì)和代碼的應(yīng)用GRASP模式：是General Responsibility Assignment Software Patterns的

6、縮寫，這些模式不是設(shè)計(jì)模式，而是對(duì)象設(shè)計(jì)的基本原則，關(guān)注對(duì)象設(shè)計(jì)最重要的方面分配職責(zé)給類，并不強(qiáng)調(diào)體系結(jié)構(gòu)的設(shè)計(jì)；具體的類型參加條目8設(shè)計(jì)模式：對(duì)可重復(fù)的設(shè)計(jì)結(jié)構(gòu)進(jìn)行抽象，由類和/或?qū)ο蟮囊蕾?、結(jié)構(gòu)、交互或轉(zhuǎn)換組成，提取了設(shè)計(jì)經(jīng)驗(yàn)的精化；設(shè)計(jì)模式有4個(gè)要素，模式名增加設(shè)計(jì)師詞匯，問題目的、上下文、何時(shí)使用，解決方案類似UML的結(jié)構(gòu)、抽象代碼，成果（Consequences）結(jié)果和折中模塊化模塊間關(guān)系：Connection指向定義在別處的某個(gè)label或地址的引用，結(jié)構(gòu)化的定義。耦合是衡量模塊間關(guān)系復(fù)雜度的度量Connection數(shù)量接口最小化（Minimize Interfaces）；Degr

7、ee衡量耦合兩個(gè)模塊的連接強(qiáng)度。Connection的Degree衡量：引用模塊本身（接口）還是其內(nèi)部（實(shí)現(xiàn)）；被傳送和接收的是什么：數(shù)據(jù)、印記、控制、完全依賴模塊的Connection：與公共環(huán)境（General，Scoped）：在共有這個(gè)連接的模塊間建立耦合；封裝將會(huì)降低耦合抽象和分解，將潛在共享元素分組，限制每一組的訪問途徑到可能的最小模塊子集。假設(shè)N1+N2=N, M1+M2=M如果M個(gè)模塊共享N個(gè)元素潛在連接數(shù)N*M，即(N1+N2) *(M1+M2)= N1*M1+N2*M2+ N1*M2+N2*M1如果M1個(gè)模塊共享N1個(gè)元素，M2個(gè)模塊共享N2個(gè)元素潛在連接數(shù)（N1*M1+N2

8、*M2）與其他模塊：連接復(fù)雜性取決于陳述或者理解它需要多少信息。顯性關(guān)系好于隱形的，最好死語法上顯性的；越多Syntactic單元耦合度越高，更簡(jiǎn)單的接口。引用模塊本身的連接耦合度低于引用別的模塊內(nèi)部元素的連接針對(duì)接口編程模塊化原則：職責(zé)分配，與自己相關(guān)的設(shè)計(jì)決策來表示而不知道其他模塊，提供實(shí)現(xiàn)上的靈活性，不用處理步驟表示，高內(nèi)聚低耦合結(jié)構(gòu)化的內(nèi)聚與耦合類型；耦合（由上而下 耦合度升高，越來越不好）：數(shù)據(jù)耦合（Data Coupling）剛剛好的數(shù)據(jù)；印記耦合（Stamp Coupling）數(shù)據(jù)多于必須；控制耦合（Control Coupling）除數(shù)據(jù)外傳遞控制元素；公共耦合（Common

9、Coupling）內(nèi)容耦合（Content Coupling）數(shù)據(jù)和控制元素混合；通過一個(gè)模塊修改另一個(gè)模塊代碼，或者目標(biāo)模塊對(duì)于進(jìn)行修改的模塊非常依賴數(shù)據(jù)耦合明顯優(yōu)于印記耦合，數(shù)據(jù)耦合也優(yōu)于控制耦合，但印記耦合和控制耦合需要視情況而定；內(nèi)聚得到獨(dú)立模塊的方法：減少不在同一模塊內(nèi)元素之間的關(guān)系，增加在同一模塊內(nèi)元素之間的關(guān)系；聯(lián)結(jié)（Binding）是衡量?jī)?nèi)聚的度量值。類型（由上至下越來越差好，第一個(gè)最差，后兩個(gè)最好）：偶然（Coincidental）：沒有Binding，語句湊巧放在一起邏輯（Logical）：通過邏輯相似性binding，比如都是編輯，典型的例子：如果是A，則按A規(guī)則編輯；如

10、果是B，則按B規(guī)則編輯。時(shí)序/臨時(shí)（Temporal）：通過邏輯相似性和時(shí)間binding，即元素間有時(shí)序關(guān)系，典型例子：初始化或終止方法通信（Communicational）：其實(shí)與時(shí)序比較沒有很明確的優(yōu)劣關(guān)系；通過邏輯相似性和數(shù)據(jù)binding，元素間共用數(shù)據(jù)順序（Sequential）：解決同一個(gè)問題來binding，一個(gè)元素的輸出是另一個(gè)的輸入；比上面的耦合都好，因?yàn)镾ame的比Similarity的binding強(qiáng)功能（Functional）：通過共同的一個(gè)目標(biāo)binding，所有元素與一個(gè)功能相關(guān)，最好的內(nèi)聚；典型例子：計(jì)算平方根，最短路徑問題，壓縮數(shù)據(jù)庫；適用于N:M問題信息（I

11、nformational）類型判斷方法：用一句話描述模塊，復(fù)合語句動(dòng)詞數(shù)大于1，多于一個(gè)功能，很可能是交互或順序；有時(shí)間詞語“第一”、“接著”等等，很可能是順序或者時(shí)序；沒有單一目標(biāo)，很可能是邏輯。面向?qū)ο蟮鸟詈项愋?；類型交互耦合（Interaction Coupling） 單交互耦合，兩個(gè)類之間的方法調(diào)用或者屬性使用，與經(jīng)典的模塊間耦合定義最相似，不包括繼承，參數(shù)和屬性不包括類的形式。組件耦合（Component Coupling）：一處定義多處使用，類和對(duì)象級(jí)別，一個(gè)類作為另一個(gè)類的實(shí)例變量使用，不包括繼承，通常是類級(jí)別。四種組件耦合形式：完全變量（Whole variable）聚合（Ag

12、gregation）；參數(shù)方法參數(shù)；創(chuàng)建者某個(gè)方法的局部變量；隱藏另一個(gè)對(duì)象提供；隱式的（Hidden）組件耦合：最壞的耦合，隱藏的組件耦合指一個(gè)對(duì)象沒有出現(xiàn)在規(guī)格說明和實(shí)現(xiàn)中，但是卻在另一個(gè)類的方法使用中被使用。這種情況的典型例子就是方法返回值直接被用作另一個(gè)方法的參數(shù)不允許串聯(lián)（cascading）消息的使用。Demeter法則：類可以使用本身，可以使用自己的成員變量，可以使用被給予的對(duì)象，可以使用自己創(chuàng)建的對(duì)象分散的（Scattered）組件耦合：一個(gè)類在另一個(gè)類實(shí)現(xiàn)中定義某個(gè)局部變量或者實(shí)例變量的時(shí)候被使用，但是沒有出現(xiàn)在這個(gè)類的規(guī)格說明中；聚合全局，局部實(shí)例局部。說明的（Specif

13、ied）組件耦合：每當(dāng)一個(gè)類作為另一個(gè)類的組件時(shí)，都會(huì)包括在這個(gè)類的規(guī)格說明中；Design by Contract，提供（Suffered）的接口說明的，需要（Required）的接口使用的繼承耦合（Inheritance Coupling）：父類的信息對(duì)于子類來說是Specified；有父類引用時(shí)，子類可以修改、精化、擴(kuò)展修改（Modification）繼承耦合：不按規(guī)則和限制的修改，最壞的繼承耦合，對(duì)多態(tài)有害，如果Client使用父引用，父子方法都需要；這種耦合式隱式的，有兩個(gè)連接，更復(fù)雜精化（Refinement）繼承耦合：定義新的信息，繼承的信息僅根據(jù)定義好的規(guī)則改變；Client使

14、用父引用，整個(gè)父的部分和子的精化是需要的，1+個(gè)連接；這種耦合是必須的擴(kuò)展（Extension）繼承耦合：子類只是增加方法和成員變量，沒有修改也沒有精化繼承的那些；Client使用父引用，只有父需要；1個(gè)連接繼承降低耦合：精化和擴(kuò)展繼承耦合中，父子類間的交互耦合忽略；這樣對(duì)象級(jí)別的耦合存留，但是類級(jí)別耦合減少了類間的耦合度量（不是重點(diǎn)，應(yīng)該不考）：Coupling between object classes（CBO），越低越好，計(jì)算一個(gè)類A中其他類的數(shù)量，這些類滿足以下條件使用A中的方法或變量或包含A使用的方法或變量不包含繼承Response for a class（RFC）：（方向（Dir

15、ection）很重要）一個(gè)對(duì)象接受一條消息后可能會(huì)有響應(yīng)的方法的數(shù)量，不包括繼承，包含嵌套的方法調(diào)用，越低越好Message passing coupling（MPC）：一個(gè)類局部位置定義的發(fā)送（send）語句的數(shù)量，越低越好；這個(gè)指數(shù)指示局部方法對(duì)其他類的方法的依賴程度Data abstraction coupling（DAC）：擁有依賴于其他類定義的ADT類型的屬性的數(shù)量，越低越好Ce and &D（efferent and afferent coupling）：輸出輸入耦合，越低越好Depth of the inheritance tree（DIT）：從節(jié)點(diǎn)到樹根的最長(zhǎng)路徑長(zhǎng)。DIT增長(zhǎng)

16、，由于繼承深度增加，則類的行為更難預(yù)測(cè)；正面效應(yīng)DIT大表示許多方法可能被復(fù)用Number of children（NOC）：直接附屬于子類的父類的計(jì)數(shù)；NOC增加，則復(fù)用增加，抽象被淡化，測(cè)試量增加對(duì)給出的例子：判斷其內(nèi)聚和耦合的類型，并將其修正為正確的類型。分析其Connection類型，計(jì)算不同Connection類型的數(shù)量。信息隱藏最有可能改變的設(shè)計(jì)領(lǐng)域硬件依賴輸入輸出格式非標(biāo)準(zhǔn)語言特性和庫函數(shù)；困難的設(shè)計(jì)和實(shí)現(xiàn)領(lǐng)域復(fù)雜數(shù)據(jù)結(jié)構(gòu)，被不止一個(gè)類使用的數(shù)據(jù)結(jié)構(gòu)，或者你還沒有得到滿意設(shè)計(jì)的數(shù)據(jù)結(jié)構(gòu)復(fù)雜邏輯全局變量數(shù)據(jù)大小限制，例如數(shù)組聲明和循環(huán)限制；業(yè)務(wù)規(guī)則；計(jì)算機(jī)系統(tǒng)嵌入過程對(duì)簡(jiǎn)單的應(yīng)用，

17、按照“處理流程”與“信息隱藏”兩種方式分別給出設(shè)計(jì)描述。典型例子：KWIC處理流程（功能）信息隱藏：比較：一般性比較：兩個(gè)系統(tǒng)可能使用相同的數(shù)據(jù)結(jié)構(gòu)和算法，區(qū)別在于他們劃分成工作單元的方式；即使在可運(yùn)行的表示上是相同的系統(tǒng)本質(zhì)上也不同，其他表示有變化、文檔化和理解可變性比較：設(shè)計(jì)決策變化，模塊化2普遍表現(xiàn)較好獨(dú)立開發(fā)：模塊化1必須先設(shè)計(jì)好所有數(shù)據(jù)結(jié)構(gòu)才能開始并行開發(fā)，需要復(fù)雜的描述；模塊化2必須設(shè)計(jì)好接口才能開始并行開發(fā)，僅需要簡(jiǎn)單描述可理解性：模塊化2比較好，主觀判斷和針對(duì)接口編程對(duì)簡(jiǎn)單的應(yīng)用，解釋其Module GuideModule Guide：層次式結(jié)構(gòu)化文檔；幫助開發(fā)人員和維護(hù)人員找

18、到變更影響到的模塊；模塊化結(jié)構(gòu)的目標(biāo)：每個(gè)模塊的結(jié)構(gòu)應(yīng)當(dāng)可以簡(jiǎn)單到全部理解；要改變一個(gè)模塊應(yīng)當(dāng)不需要知道別的模塊的實(shí)現(xiàn)也不會(huì)影響其他模塊的行為；一個(gè)較大的軟件變化應(yīng)當(dāng)可以通過一系列單獨(dú)模塊的獨(dú)立變化實(shí)現(xiàn)；軟件工程師應(yīng)當(dāng)在不了解內(nèi)部實(shí)現(xiàn)的情況下了解模塊的職責(zé)；有良好定義的關(guān)注點(diǎn)應(yīng)當(dāng)能夠在不研究無關(guān)模塊的情況下容易的確認(rèn)相關(guān)模塊；對(duì)于每一個(gè)模塊，Module Guide陳述：每個(gè)模塊關(guān)聯(lián)的secrets：Primary Secret軟件設(shè)計(jì)者專有的隱藏信息，Secondary secret實(shí)現(xiàn)隱藏PS的模塊時(shí)做出的實(shí)現(xiàn)設(shè)計(jì)決策在整個(gè)系統(tǒng)運(yùn)作中單個(gè)模塊所扮演的角色每個(gè)模塊提供的facilities例

19、子：模塊化層次，模塊按照其secret類型的不同進(jìn)行組織；第一層，Hardware，behavior，software利用文檔的設(shè)計(jì)（Design through Documentation）：增加了產(chǎn)品完整性和軟件可復(fù)用性的可能性Module GuideModule Interface Document：與MG不同，包含精確完整的模塊接口描述Module Design Document：模塊每個(gè)實(shí)現(xiàn)的內(nèi)部實(shí)際文檔Requirements Document：MG引用該文檔來有關(guān)的變更軟件體系結(jié)構(gòu)風(fēng)格軟件體系結(jié)構(gòu)風(fēng)格定義：用結(jié)構(gòu)化組織的模式來定義一系列系統(tǒng)，并定義組件和連接件的vocabular

20、y以及其如何結(jié)合的限制；描述一類體系結(jié)構(gòu)或重要的體系結(jié)構(gòu)片段，實(shí)踐過程中被重復(fù)發(fā)現(xiàn)，是一組緊密相關(guān)的設(shè)計(jì)決策，具有允許重用的已知屬性不同組件的風(fēng)格：對(duì)象（設(shè)計(jì)模式）、模塊、進(jìn)程、物理單元模塊風(fēng)格：進(jìn)程風(fēng)格描述或比較相關(guān)風(fēng)格模塊風(fēng)格描述點(diǎn)：簡(jiǎn)要規(guī)則流程敘述，組件連接件和限制是什么，優(yōu)缺點(diǎn)，適用系統(tǒng)；比較點(diǎn)：算法變化，數(shù)據(jù)表示變化，附加特性（功能），性能空間時(shí)間，復(fù)用Call-and-ReturnMain-program-and-subroutine：層次式分解程序，單線程控制，子系統(tǒng)結(jié)構(gòu)隱藏，每個(gè)組件接受父組件的控制；組件是過程、函數(shù)或者模塊，連接件是他們之間的調(diào)用，限制是控制始于調(diào)用層次的頂層

21、然后向下移動(dòng)；過程清晰易于理解，正確性控制強(qiáng)，變更和復(fù)用困難，可能是公共耦合，適用順行系統(tǒng)和正確性攸關(guān)系統(tǒng)Object-oriented（數(shù)據(jù)抽象）：通過封裝數(shù)據(jù)表示和相關(guān)的操作幫助提高修改性，對(duì)象保證自己數(shù)據(jù)表示的完整性，每個(gè)對(duì)象都是匿名的代理，只能通過固定格式的過程調(diào)用來使用對(duì)象；組件是對(duì)象或模塊，連接件是函數(shù)或調(diào)用；在不影響使用者的情況下可以修改實(shí)現(xiàn)，系統(tǒng)分解為一系列匿名代理，但一個(gè)對(duì)象要與另一個(gè)對(duì)象交互必須知道對(duì)方的標(biāo)識(shí)符，并且會(huì)有副作用問題，從而產(chǎn)生不可預(yù)期的操作，適用于有一個(gè)中心問題并須保護(hù)相關(guān)信息（數(shù)據(jù)）的應(yīng)用Pipe and Filter：每個(gè)過濾器處理數(shù)據(jù)然后傳遞給下一個(gè)過濾

22、器，每當(dāng)有數(shù)據(jù)需要處理時(shí)過濾器都會(huì)運(yùn)行，數(shù)據(jù)共享嚴(yán)格控制在管道的傳遞上；組件是過濾器，連接件是管道，限制是過濾器之間不共享狀態(tài)，過濾器不知道上下游的標(biāo)識(shí)符，輸出正確性不依賴于過濾器順序；適易于理解，支持重用，維護(hù)和增強(qiáng)容易，允許特定種類的專門分析，支持并發(fā)，交互不佳，需要額外空間，解析增加性能流失和過濾器編寫的復(fù)雜性，用于在有序數(shù)據(jù)上定義一系列獨(dú)立計(jì)算的應(yīng)用；特化形式Pipelines（線性拓?fù)洌┖虰atch Sequential（pipeline退化版）Implicit Invocation：組件發(fā)起一至多個(gè)事件，也可以注冊(cè)某個(gè)方法來響應(yīng)某個(gè)事件，當(dāng)時(shí)間發(fā)生時(shí)，連接件調(diào)用所有注冊(cè)該事件的方法

23、，封裝共享數(shù)據(jù)，避免暴露存儲(chǔ)格式給計(jì)算模塊，數(shù)據(jù)更改時(shí)計(jì)算被隱式調(diào)用，典型應(yīng)用事件；組件是agent（對(duì)象，過程，進(jìn)程），連接件是廣播中介（事件處理器），限制是事件發(fā)起者不知道事件影響那些組件，無法假設(shè)處理順序以及處理結(jié)果；復(fù)用支持極佳，系統(tǒng)演化容易，但難以保證正確性和完整性，且測(cè)試和診斷困難，適用于擁有松散耦合的組件集、每個(gè)都可能執(zhí)行一些使其他組件進(jìn)行處理的操作的應(yīng)用上面四種比較Main-program-and-subroutineObject-OrientedPipe and FilterImplicit InvocationChange in algorithmBadMediumGood

24、GoodChange in data representationBadGoodMediumMediumChang in functionsMediumMediumGoodMediumMake system interactiveMediumMediumBadMediumSpace performanceGoodGoodBadGoodTime performanceBadBadMediumGoodReuse componentsBadMediumGoodGoodRepository（Blackboard）：組件是一個(gè)表示系統(tǒng)正確狀態(tài)的中心數(shù)據(jù)結(jié)構(gòu)，一組操作中心數(shù)據(jù)結(jié)構(gòu)的獨(dú)立組件（agent），

25、連接件是過程調(diào)用和直接內(nèi)存存取，限制是所有agent應(yīng)當(dāng)獨(dú)立并且依賴共享數(shù)據(jù)，檢查數(shù)據(jù)狀態(tài)并做出反應(yīng)（Pull vs. Push）；存儲(chǔ)大量數(shù)據(jù)的方便方式，集中化管理，必須先對(duì)數(shù)據(jù)模型達(dá)成一致，中心數(shù)據(jù)體會(huì)成為瓶頸，數(shù)據(jù)演化昂貴，適用于中心問題是建立擴(kuò)充和維護(hù)阻隔復(fù)雜中心信息體的應(yīng)用Repository vs. Blackboard：前者使用pull模型，易于實(shí)現(xiàn)但客戶端復(fù)雜并且需要輪詢數(shù)據(jù)；后者使用push模型，客戶端編程簡(jiǎn)化但需要復(fù)雜的結(jié)構(gòu)Layered：組件是一組過程或?qū)ο?，連接件是過程調(diào)用和限制可見性的方法調(diào)用，限制是系統(tǒng)組織成層次結(jié)構(gòu)，每層給上層提供服務(wù)并作為下層的client，躍層

26、是不允許的；設(shè)計(jì)基于不同層次的抽象，更改一層最多再影響兩層，同層可互換提供服務(wù)增強(qiáng)復(fù)用，但不是所有系統(tǒng)都有明確的層次結(jié)構(gòu)，并且性能可能會(huì)需要躍層訪問以及實(shí)現(xiàn)部分訪問，適用于擁有明確的服務(wù)種類從而可層次式組織的應(yīng)用，例如層次式通信協(xié)議和操作系統(tǒng)，特例是異常一般是無層次直接交互的Model-View-Controller：model子系統(tǒng)設(shè)計(jì)為不依賴任何view子系統(tǒng)和controller子系統(tǒng)，其狀態(tài)的變化會(huì)傳遞給view子系統(tǒng)；model組件負(fù)責(zé)維護(hù)領(lǐng)域知識(shí)和通知view變化，view組件負(fù)責(zé)顯示信息并傳遞用戶指示給controller，controller負(fù)責(zé)更改model狀態(tài)和選擇響應(yīng)vi

27、ew，連接件是過程調(diào)用、消息、事件、直接內(nèi)存存取；允許一個(gè)model上建立多個(gè)獨(dú)立view，view可同步，可“插拔”（易于修改）的view和controller，但增加了復(fù)雜性，view獲取數(shù)據(jù)效率不高，與流行UI工具不十分兼容，適用于UI修改容易并且可以運(yùn)行時(shí)修改、UI的修改不應(yīng)該影響功能部分設(shè)計(jì)和代碼的應(yīng)用比較進(jìn)程風(fēng)格Point-to-point：消息被發(fā)送給一個(gè)唯一可確定的接收者，空間上雙方需要互相了解，時(shí)間上必須是同步激活Publish-Subscribe：多個(gè)應(yīng)用接受相同消息，發(fā)布者和訂閱者松散耦合，消息傳送基于事件發(fā)布，事件類型層次化組織；組件是發(fā)布者和訂閱者，連接件是事件Rou

28、ter復(fù)雜并且負(fù)責(zé)失?。晃锢韱卧L(fēng)格Client-Server：分布式系統(tǒng)的特例；組件是client，連接件是RPC-based interaction protocols；server不知道client的數(shù)量或identities，而client知道server的identityThree-Tier（N-Tier）：表示層（接口層或前端）、應(yīng)用業(yè)務(wù)邏輯層、數(shù)據(jù)層（存儲(chǔ)層或后端），像是在client/server間再加一層，提供了用戶接口和業(yè)務(wù)邏輯的分離Peer-to-Peer：client/server的泛化，更難實(shí)現(xiàn)；組件是匿名的既作為client又作為server，連接件是同步或異步消息

29、傳遞但一般不共享內(nèi)存，交互的拓?fù)浣Y(jié)構(gòu)差異性和動(dòng)態(tài)性較大Distributed SystemDistributed Objects（middleware）Distributed Resources（http）Distributed Services（web service）比較全局分析的步驟軟件體系結(jié)構(gòu)設(shè)計(jì)的兩個(gè)基本部分：設(shè)計(jì)描述系統(tǒng)結(jié)構(gòu)使用四個(gè)互補(bǔ)view來減少體系結(jié)構(gòu)設(shè)計(jì)和理解的復(fù)雜性；第二部分是全局分析產(chǎn)生描述上下文和設(shè)計(jì)決策理由的文檔。將兩個(gè)部分集成，由一個(gè)初始的view框架開始設(shè)計(jì)，從而做出決策全局分析步驟：識(shí)別影響體系結(jié)構(gòu)的外部影響因素和關(guān)鍵需求分析因素（constraints和質(zhì)量

30、），分三步識(shí)別并描述因素，分為產(chǎn)品（系統(tǒng)質(zhì)量）、組織（業(yè)務(wù)質(zhì)量）和技術(shù)（系統(tǒng)和業(yè)務(wù)）三大類描述因素，敘述這些因素的flexibility（別的因素變）和changeability（自己變）特征分析因素的impact（自己變），相關(guān)的因素以及影響范圍開發(fā)策略，分三步識(shí)別issue和有影響的因素，將因素與問題關(guān)聯(lián)，分析限制和約束開發(fā)解決方案和特定的策略識(shí)別相關(guān)策略分析他們，得出設(shè)計(jì)體系結(jié)構(gòu)的策略根據(jù)分析類圖，建立基本的設(shè)計(jì)類圖轉(zhuǎn)換領(lǐng)域模型：將角色轉(zhuǎn)變?yōu)榻涌陬?；添加角色domain類；添加啟動(dòng)類；轉(zhuǎn)換或添加控制器和協(xié)調(diào)器；添加數(shù)據(jù)類型類；轉(zhuǎn)換或添加容器類；轉(zhuǎn)換或添加工程設(shè)計(jì)關(guān)聯(lián)分配職責(zé)：操作職責(zé)通過

31、操作滿足，數(shù)據(jù)職責(zé)通過屬性滿足，有類協(xié)作職責(zé)驅(qū)動(dòng)的分解：幫助實(shí)現(xiàn)高內(nèi)聚低耦合，確保模塊職責(zé)不重疊，只有操作或數(shù)據(jù)對(duì)完成模塊職責(zé)有益時(shí)才將其放入該模塊，一個(gè)模塊完成職責(zé)所需全部操作和數(shù)據(jù)都應(yīng)放于該模塊繼承是一個(gè)類和一個(gè)或多個(gè)超類之間的關(guān)系，子類有超類的每個(gè)屬性和操作不要僅僅為重用使用繼承只有當(dāng)有泛化關(guān)系（kind-of）的時(shí)候才使用繼承可以重新考慮類結(jié)構(gòu)來實(shí)現(xiàn)重用代理：一個(gè)模塊將職責(zé)委托給另一個(gè)，在不違反繼承約束的情況下允許了重用，增加了重用、靈活性和可配置性有幾種控制流處理方式？進(jìn)行比較控制器：做出決策并指導(dǎo)其他組件的程序組件，因?yàn)樗麄冊(cè)诮换ブ械闹行牡匚欢种匾刂茊⑹荆罕苊獯蟛糠窒a(chǎn)生于

32、一個(gè)單一組件的交互設(shè)計(jì)；保持組件小型；確保操作職責(zé)不僅僅分配給少數(shù)組件；確保操作職責(zé)與數(shù)據(jù)職責(zé)一致；讓組件代理盡可能多的低層任務(wù)；避免需要每個(gè)組件發(fā)送許多信息的交互Demeter法則：一個(gè)對(duì)象obj的操作只應(yīng)當(dāng)向以下實(shí)體發(fā)送信息：obj，obj的屬性，該操作的參數(shù)，所屬集合為該操作的參數(shù)或者obj的屬性的元素，該操作創(chuàng)建的對(duì)象，全局類或?qū)ο罂刂骑L(fēng)格（Control Styles）：決策制定在組件之間分布的方式；有以下幾種集中式（Centralized）：少數(shù)控制器做出所有重要決策。容易找到?jīng)Q策制定的位置找到，也容易明白決策如何制定以修改決策制定過程；控制器可能會(huì)膨脹，會(huì)變得大而復(fù)雜，難以理解、

33、維護(hù)和測(cè)試等；控制器可能將其他組件視為數(shù)據(jù)存取部件，這將增加耦合，破壞信息隱藏委托式（Delegated）：決策制定分散在程序中，少數(shù)控制器做出重要決定?？刂破髋c少數(shù)組件耦合，信息隱藏更好，程序容易分層；這種風(fēng)格是較為推薦的分散式（Dispersed）：決策制定廣泛分布在程序中，少數(shù)（或沒有）組件自己做出決策。有許多具有小數(shù)據(jù)少量職責(zé)的組件，難以理解控制流，組件本身無法完成很多工作從而增加耦合，難以隱藏信息，低內(nèi)聚，不太滿足模塊化原則GRASP模式GRASP：是General Responsibility Assignment Software Patterns的縮寫，這些模式不是設(shè)計(jì)模式，而

34、是對(duì)象設(shè)計(jì)的基本原則，關(guān)注對(duì)象設(shè)計(jì)最重要的方面分配職責(zé)給類，并不強(qiáng)調(diào)體系結(jié)構(gòu)的設(shè)計(jì)；Expert（專家模式）：最基本的問題誰負(fù)責(zé)得知某些信息；解決方法將這個(gè)職責(zé)分配給需要信息來完成自己職責(zé)的類；維護(hù)信息封裝，低耦合高內(nèi)聚，可能使類變得很復(fù)雜Creator（創(chuàng)建者模式）：?jiǎn)栴}誰負(fù)責(zé)創(chuàng)建某類的新實(shí)例；解決方法賦予B創(chuàng)建A的職責(zé)如果（B聚合A，B包含A，B記錄A的實(shí)例，B密切使用A，B有創(chuàng)建A的初始數(shù)據(jù)），其中第一條或第二條最好；類擁有創(chuàng)建需要引用的對(duì)象的職責(zé)來減少Connection以降低耦合，自己創(chuàng)建實(shí)例可以避免依賴于其他類為條目創(chuàng)建實(shí)例Low Coupling（低耦合）：?jiǎn)栴}低依賴度、高復(fù)用性

35、；解決方案分配職責(zé)保持低耦合；類易于維護(hù)和復(fù)用，變更本地化High Cohesion（高內(nèi)聚）：?jiǎn)栴}使得復(fù)雜性在可管理的范圍內(nèi)；解決方案分配職責(zé)保持高內(nèi)聚，一個(gè)功能領(lǐng)域的中等規(guī)模職責(zé)，與其他類協(xié)作完成任務(wù)；類易于維護(hù)和理解，增益低耦合，職責(zé)粒度適中故而為復(fù)用提供支持；Rule of thumb（首要原則）Controller（控制器）：?jiǎn)栴}誰負(fù)責(zé)處理系統(tǒng)事件；解決方案如果程序接收不是從圖形接口來的外部源事件，添加一個(gè)事件類來解耦事件源和處理事件的對(duì)象；將處理系統(tǒng)事件消息的職責(zé)分配給類（業(yè)務(wù)或者全局組織facade controller，全局“系統(tǒng)”facade controller，領(lǐng)域中執(zhí)行

36、工作的活動(dòng)體，人工類型（純虛構(gòu)）use case controller）；增加了復(fù)用的可能性，將外部事件源和內(nèi)部事件處理的類型和行為獨(dú)立開，論證用例的狀態(tài)，確保系統(tǒng)操作以合法的順序出現(xiàn)，或能論證用例中活動(dòng)和操作的現(xiàn)狀態(tài)；使用Controller對(duì)象保證外部事件源和內(nèi)部事件處理的類型和行為獨(dú)立開，擁有更多的職責(zé)controller對(duì)象可能高耦合低內(nèi)聚Polymorphism（多態(tài)）：?jiǎn)栴}誰處理基于類型的多個(gè)選擇；解決方案基于類型有多種行為選擇時(shí)，使用多態(tài)方法調(diào)用來選擇行為而不是使用if語句來測(cè)試類型；比顯示選擇邏輯更簡(jiǎn)單和可靠，更易于增加附加行為，但增加了設(shè)計(jì)中類的數(shù)量，也使得代碼更難跟蹤Pur

37、e Fabrication（純虛構(gòu)）：?jiǎn)栴}如何不違背高內(nèi)聚低耦合；解決方案將高內(nèi)聚職責(zé)結(jié)合分配給在問題域中沒有對(duì)用的人工類，只有狀態(tài)或只有行為，從而支持高內(nèi)聚低耦合和復(fù)用；由于職責(zé)被分配給關(guān)注一個(gè)非常特化的相關(guān)任務(wù)集的類而得到高耦合，適中粒度的純虛構(gòu)類增加復(fù)用的可能性；例子，操作數(shù)據(jù)庫的類，適用場(chǎng)景分離表示層和模型層、分離平臺(tái)（facilities）和模型層、分離復(fù)雜行為或復(fù)雜數(shù)據(jù)結(jié)構(gòu)Indirection（間接）：?jiǎn)栴}如何避免直接耦合、解耦對(duì)象以支持低耦合和高復(fù)用可能性；解決方案將職責(zé)分配給一個(gè)中間對(duì)象來協(xié)調(diào)其他組件或服務(wù)，使他們不會(huì)直接耦合；與可變性解耦，提升復(fù)用Protected Var

38、iations（差異性保護(hù)）：?jiǎn)栴}如何設(shè)計(jì)對(duì)象、子系統(tǒng)和系統(tǒng)以便這些元素的差異性或不穩(wěn)定性不會(huì)對(duì)其他元素產(chǎn)生非預(yù)期的影響；解決方案識(shí)別可預(yù)期的差異點(diǎn)和不穩(wěn)定點(diǎn)，分配職責(zé)以創(chuàng)建一個(gè)穩(wěn)定的接口；信息隱藏，數(shù)據(jù)驅(qū)動(dòng)（配置文件），服務(wù)lookup（運(yùn)行時(shí)注冊(cè)），interpreter驅(qū)動(dòng)（泛化模塊），映射或元數(shù)據(jù)級(jí)別設(shè)計(jì)（組件代替），統(tǒng)一存?。▍f(xié)議依賴），LSP（多態(tài)），Demeter法則（限制交互路徑）對(duì)外部事件交互，應(yīng)該如何處理？示例Good design： presentation layer decoupled from problem domainBad design ：presentati

39、on layer coupled to problem domain對(duì)給定場(chǎng)景，判斷職責(zé)的分配設(shè)計(jì)模式普通Programming to Interfaces有哪些手段？集合繼承：允許定義一系列接口一樣的對(duì)象，導(dǎo)出類共享基類接口，所有子類使用抽象類的接口響應(yīng)請(qǐng)求，繼承樹上的類算一個(gè)耦合LSP：所有導(dǎo)出類必須可作為其基類的代替集合類型Programming to Interfaces有哪些手段？迭代器模式目的：提供一種順序存取聚集對(duì)象的元素又不暴露底層表達(dá)的途徑；支持聚集對(duì)象的多重遍歷，為遍歷不同的聚集結(jié)構(gòu)提供統(tǒng)一接口（支持多態(tài)的迭代）結(jié)構(gòu)成果針對(duì)接口編程，信息隱藏支持遍歷聚集的差異性簡(jiǎn)化聚集的接

40、口一個(gè)聚集可以有多于一個(gè)遍歷迭代機(jī)制設(shè)計(jì)方案控制：外部迭代控制和內(nèi)部迭代控制（更好）代理模式問題：為另一個(gè)對(duì)象提供對(duì)其進(jìn)行控制存取的代理或中介Remote Proxy：為不同地址空間的對(duì)象提供本地表示Virtual Proxy： 按需創(chuàng)建、也可能緩存昂貴的對(duì)象Protection Proxy：控制對(duì)原始對(duì)象的存取，當(dāng)存取權(quán)限不同時(shí)有用結(jié)構(gòu)Subject為抽象類/接口，RealSubject和Proxy繼承Subject，client永遠(yuǎn)使用的是Proxy，Proxy負(fù)責(zé)代理安全的調(diào)用，如果不安全調(diào)用出現(xiàn)就會(huì)有異?；蚓娉晒阂M(jìn)存取對(duì)象的一層間接原型模式：使用原型實(shí)例指定創(chuàng)建的對(duì)象種類，通過復(fù)

41、制原型的方式創(chuàng)建新對(duì)象結(jié)構(gòu)De-Coupling有哪些手段？避免重復(fù)只做一次：重復(fù)往往代表著耦合，修改一部分重復(fù)代碼表示要修改其他的DIP：Dependency Inversion Principle，依賴倒置原則，即細(xì)節(jié)應(yīng)當(dāng)依賴于抽象，抽象不應(yīng)當(dāng)依賴于細(xì)節(jié)；在要被其他模塊implement的模塊中定義接口，這是一種去除依賴減少耦合的基本方式繼承：共性和差異性設(shè)計(jì)模式中介模式問題：一組對(duì)象以良好定義但復(fù)雜的方式交互，通常為非結(jié)構(gòu)化的依賴；由于與許多對(duì)象的引用和通信對(duì)象復(fù)用困難；分散在幾個(gè)類中的行為應(yīng)當(dāng)在子類不多的情況下自定義結(jié)構(gòu)Mediator定義了Colleague通信的接口，通常被告知某個(gè)

42、事件或情況了；每個(gè)Colleague知道其Mediator，需要交互與Mediator交互，向Mediator提供服務(wù)/請(qǐng)求，有對(duì)所有Colleague的共同請(qǐng)求，也有特化的成果定義封裝一組對(duì)象交互方式的對(duì)象；中介通過避免對(duì)象互相顯式引用提升了松散耦合；讓你獨(dú)立的差異交互；集中控制橋接模式問題：處理一個(gè)抽象多個(gè)實(shí)現(xiàn)的普通手段是繼承，然而這將實(shí)現(xiàn)與抽象永久綁定；這樣做不夠靈活，可能需要單獨(dú)分別修改或者擴(kuò)展抽象和實(shí)現(xiàn)解決方案：分離抽象類層次和實(shí)現(xiàn)類層次，使用代理作為二者的橋梁實(shí)例成果：解耦了接口和實(shí)現(xiàn)消除了編譯時(shí)依賴，改善了可擴(kuò)展性，對(duì)client隱藏了實(shí)現(xiàn)細(xì)節(jié)一個(gè)模塊的信息隱藏有哪兩種基本類型？

43、基本secret：外部行為vs.內(nèi)部實(shí)現(xiàn)，隱藏一個(gè)重要的設(shè)計(jì)決策的實(shí)現(xiàn)細(xì)節(jié)，只有該模塊的元素才知道該細(xì)節(jié)Facade Design（門面）模式問題：針對(duì)模塊/子系統(tǒng)的一組接口提供統(tǒng)一接口，定義高層接口使得模塊/子系統(tǒng)更易于使用解決方案成果：信息隱藏，解耦了組件的一個(gè)子系統(tǒng)和一個(gè)client附加secret：改變，隱藏對(duì)于預(yù)期的改變，把可能改變從模塊中分離開來，安排到新的類，方法或者設(shè)計(jì)單元中，使得這個(gè)可能改變的設(shè)計(jì)單元不會(huì)影響其他部分OCP：Open-Closed Principle，一個(gè)軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開放,對(duì)修改關(guān)閉策略模式：將算法從包含其的對(duì)象中抽離出來，封裝該算法（策略）為一個(gè)對(duì)象結(jié)

44、構(gòu)使用橋接模式來解決context也是可變的裝飾模式：裝飾在不改變類的代碼的情況下擴(kuò)展了一個(gè)類的實(shí)例的功能，比靜態(tài)繼承更靈活，裝飾者在幕后工作，對(duì)接口是透明的解決方案成果比靜態(tài)繼承更靈活，避免功能負(fù)擔(dān)重的類在層次中位置高，有許多相像的小對(duì)象，難以理解和調(diào)試，裝飾者和組件不一樣，所以檢查對(duì)象一致會(huì)引起問題適配器模式：將類的接口轉(zhuǎn)換成另一個(gè)client期望的接口，讓接口不兼容的類能一起工作解決方案實(shí)現(xiàn)共性與可變性有哪些手段？多態(tài)（繼承）1 of N：父為共性，子為差異性聚合M of N：整體為共性，部分為差異性；在復(fù)雜場(chǎng)景中聚合更好運(yùn)行時(shí)注冊(cè)1 of N/M of N：靜態(tài)編譯為共性，運(yùn)行時(shí)注冊(cè)為

45、差異性策略模式問題：當(dāng)許多相關(guān)類僅在行為上不同時(shí)使用策略模式提供在許多行為中配置一個(gè)類的一種行為；一個(gè)類以操作中的條件語句的形式定義許多行為時(shí)可以使用策略模式；當(dāng)你需要不同算法變種時(shí)使用；一個(gè)算法使用了client不應(yīng)當(dāng)知道的數(shù)據(jù)；當(dāng)在固定的特性中有可變的行為時(shí)使用解決方案成果：可變性和復(fù)用性，復(fù)雜，消除了條件語句但分離了邏輯，client必須知道有不同的算法狀態(tài)模式問題：對(duì)象的行為依賴于狀態(tài)，操作有許多可選結(jié)構(gòu)每個(gè)狀態(tài)有不同的選擇結(jié)構(gòu)協(xié)作：Context代理狀態(tài)State的特殊請(qǐng)求，將自己作為參數(shù)傳遞給ConcreteState對(duì)象，client只需與Context交互，可以決定是哪個(gè)Con

46、creteState對(duì)象成果：本地化狀態(tài)敏感的行為，易于添加新狀態(tài)但增加了類結(jié)構(gòu)的大小，使?fàn)顟B(tài)轉(zhuǎn)換顯式消除了潛在不一致的內(nèi)部狀態(tài)，狀態(tài)對(duì)象能被共享運(yùn)行時(shí)注冊(cè)和Call-backsCallback是可注冊(cè)給server的client方法，server可進(jìn)行調(diào)用，實(shí)現(xiàn)擴(kuò)展性的機(jī)制，作用在server對(duì)象的中間狀態(tài)上觀察者模式問題：定義對(duì)象間的一對(duì)多關(guān)系，當(dāng)一個(gè)對(duì)象改變狀態(tài)時(shí)，所有它的依賴者都被通知并自動(dòng)更新解決方案成果：靈活，可變，復(fù)用，低耦合，但更復(fù)雜，更難理解和測(cè)試當(dāng)遇到以下情形之一時(shí)使用此模式：一個(gè)對(duì)象改變需要改變別的，不知道需要改變多少；一個(gè)對(duì)象在不知道對(duì)方是誰的情況下要能夠通知其他對(duì)象，

47、松耦合命令模式根據(jù)對(duì)象的動(dòng)作參數(shù)化對(duì)象，然后在不同時(shí)間指定、排列、執(zhí)行請(qǐng)求，保存上下文信息支持undo，支持恢復(fù)目的的變更日志解決方案成果：解耦請(qǐng)求的接受者和執(zhí)行者，可以使用堆棧或隊(duì)列保存命令，易于支持undo和redo，更易于擴(kuò)展命令對(duì)象的創(chuàng)建有哪些常見解決方法？與其他對(duì)象的創(chuàng)建connection：無限制的實(shí)例，創(chuàng)建類型，簡(jiǎn)單實(shí)例化和初始化方法有：Creator模式、Coupling模式、Cohesion模式場(chǎng)景1：只有一個(gè)實(shí)例單件模式問題：有時(shí)我們只需要一個(gè)特殊類的一個(gè)實(shí)例，為安全起見多于一個(gè)即非法結(jié)構(gòu)場(chǎng)景2：有限個(gè)實(shí)例封裝對(duì)象創(chuàng)建工廠：一個(gè)職責(zé)為創(chuàng)建不同類型類的類更復(fù)雜的場(chǎng)景：類型差異

48、知道要?jiǎng)?chuàng)建實(shí)例但不知道哪種被創(chuàng)建工廠方法：不是簡(jiǎn)單工廠；定義創(chuàng)建對(duì)象的接口，但讓子類決定實(shí)例化哪個(gè)類，將類延遲創(chuàng)建到子類抽象工廠問題：目的是提供在不指定concret類的情況下創(chuàng)建一系列相關(guān)或依賴的對(duì)象的接口解決方案成果：隔離了concret類，容易更換產(chǎn)品系列，保證產(chǎn)品間的一致性；很難支持新品種的產(chǎn)品，不得不重新編寫抽象工廠和所有子類，但是在動(dòng)態(tài)語言中這并不是那么壞的事場(chǎng)景3：復(fù)雜的實(shí)例化和初始化，例如運(yùn)行時(shí)實(shí)例化和初始值差異原型模式：使用原型實(shí)例指定要?jiǎng)?chuàng)建的對(duì)象種類，然后使用原型拷貝來創(chuàng)建新對(duì)象結(jié)構(gòu)成果：運(yùn)行時(shí)增加和去除原型，通過不同的值指定新對(duì)象（添加新原型），偽動(dòng)態(tài)裝載設(shè)計(jì)模式部分所有

49、的思考題尋找一個(gè)需要訪問集合變量的場(chǎng)景；編程實(shí)現(xiàn)：Iterator Pattern和Proxy Pattern假想一個(gè)場(chǎng)景，需要通過迭代器來訪問元素的后繼(Binary Tree)；BinaryTree 類實(shí)現(xiàn)基本的二叉樹的插入查找等功能，這里不再給出；測(cè)試用的Main也不給出了下面給出迭代器，主要實(shí)現(xiàn)基本的訪問功能01 public class BinaryTreeIterator 02 Object index;03 BinaryTree bt;0405 public BinaryTreeIterator(BinaryTree bt)06 this.bt = bt;07 index = b

50、t.findMinNode(bt.head);08 0910 public Object first()11 return bt.head;12 1314 public void next()15 index = bt.successor(Node)index);16 1718 public boolean isDone()19 return index = null;20 2122 public Object currentItem()23 return index;24 25 代理模式，封裝一部分操作01 public class BinaryTreeProxy 02 private Bi

51、naryTree bt;0304 public BinaryTreeProxy(BinaryTree bt)05 this.bt = bt;06 0708 public void insert(int element)09 bt.insert(element);10 1112 public Node searchNode(int x)13 return bt.searchNode(x);14 1516 public Node findMaxNode(Node node)17 if (node = null)18 return null;19 20 if (searchNode(node.get

52、Element()= null)21 return null;22 23 return bt.findMaxNode(node);24 2526 public Node findMinNode(Node node)27 if (node = null)28 return null;29 30 if (searchNode(node.getElement()= null)31 return null;32 33 return bt.findMinNode(node);34 3536 public Node successor(Node x)37 if (x = null)38 return nu

53、ll;39 40 if (searchNode(x.getElement()= null)41 return null;42 43 return bt.successor(x);44 45 用Mediator模式實(shí)現(xiàn)CardShark游戲（P467）每一個(gè)Colleague繼承一個(gè)基類，參與者有cardsender、player、container，這些參與者需要交互的方法都是得到自己的mediator再調(diào)用mediator的方法完成的容器的狀態(tài)類3 public enum status 4 Null,PutStack,Gambling,End5 調(diào)停者（Mediator），集中式控制，保存需

54、要通信的參與者引用，重要的方法registerXXX（注冊(cè)一個(gè)參與者），noticeXXX（一個(gè)動(dòng)作）實(shí)現(xiàn)前面Bridge Pattern的示例考慮實(shí)驗(yàn)中你所負(fù)責(zé)的模塊，是否需要利用Faade模式Just for fun，不考利用Decorator解決下圖的新增功能public class WritePrinter public void write(int c)public abstract class Decorator extends WritePrintprivate WritePrint wp;public void setWritePrint(WritePrint wp) this

55、.wp = wp;Overridepublic void write(int c) public class WriteDisk extends Decorator Overridepublic void write(int c) if (wp != null) wp.write(c);Adapt enumeration to iterator（接口見右圖）下面為Adapterpublic class Adapter implements Iterator private Enumeration enumeration = new ConcreteEnumeration();public vo

56、id hasNext()enumeration.hasMoreElements();public void next()enumeration. nextElement();public void remove()/無法實(shí)現(xiàn)，只有接口1）如果一個(gè)對(duì)象集的一個(gè)行為需要協(xié)作對(duì)象來完成，但是它們?cè)趨f(xié)作對(duì)象上存在差異性，如何處理？將與其他對(duì)象連接的部分分離出去2）如果一個(gè)對(duì)象集之間除共性外，有超過個(gè)的差異行為，如何處理？每個(gè)行為都封裝出去3）如果一個(gè)對(duì)象集除了接口之外，全是差異行為，如何處理？保留接口，其他全部做成策略4）從共性和差異性角度，如何解釋Bridge模式？（Bridge非常典型的只有Interface）暴露給Client的是不變的接口，Abstraction和Implementor給出了一些共同操作的接口，但Abstraction可以有不同的實(shí)現(xiàn)，實(shí)現(xiàn)也有不同的實(shí)現(xiàn)。Abstraction是共性