體系結(jié)構(gòu)復(fù)習(xí)提綱(內(nèi)容版)

1、名詞解釋：(背誦)軟件體系結(jié)構(gòu)、4+1 View、軟件體系結(jié)構(gòu)設(shè)計(jì)決策、（三出一）實(shí)現(xiàn)類型 軟件實(shí)現(xiàn)機(jī)制 提供方 隱式（Implicit） 程序調(diào)用（Procedure Call） 編程語(yǔ)言機(jī)制 共享變量（Shared variable） 消息（Message） 平臺(tái)、框架或高級(jí)語(yǔ)言機(jī)制 管道（Pipe） 事件（Event） 遠(yuǎn)程過(guò)程調(diào)用（RPC） 網(wǎng)絡(luò)協(xié)議（NetworkProtocol） 數(shù)據(jù)庫(kù)訪問(wèn)協(xié)議（Database Access Protocol） 顯式（Explicit） 適配器（Adaptor） 復(fù)雜邏輯實(shí)現(xiàn) 委托（Delegator） 中介（Intermediate） 軟件體系

2、結(jié)構(gòu)剔除載體（程序機(jī)制）影響，進(jìn)行邏輯設(shè)計(jì) 實(shí)現(xiàn)系統(tǒng)大部分的質(zhì)量（8085%） 4+1 ViewLogical ViewEnd-user FunctionalityImplementation ViewProgrammers Configuration management Pocess ViewPerformanceScalabilityThroughput System integratorsDeployment ViewSystem topologyCommunication ProvisioningSystem engineeringConceptualPhysicalUse Case

3、 ViewIBM提出的一種multi-point的體系結(jié)構(gòu)模型，共有5個(gè)viewpoint，關(guān)注點(diǎn)在設(shè)計(jì)上，特別適用于迭代設(shè)計(jì)過(guò)程，由4個(gè)View（邏輯、開(kāi)發(fā)、進(jìn)程和物理）以及1個(gè)特殊viewpoint場(chǎng)景來(lái)描述體系結(jié)構(gòu)，不同的涉眾可選取自己關(guān)系的view來(lái)理解。邏輯視圖為面向?qū)ο蟮姆纸猓申P(guān)鍵的抽象部件連接件以及配置組成，考慮功能需求，針對(duì)終端用戶；進(jìn)程視圖為進(jìn)程分解，有多個(gè)層次，包含一個(gè)進(jìn)程網(wǎng)絡(luò)，軟件分解為一組可執(zhí)行的工作單元，考慮非功能需求，針對(duì)集成人員；開(kāi)發(fā)視圖為子系統(tǒng)分解，是產(chǎn)品線的基礎(chǔ)，有模塊和子系統(tǒng)圖組成，考慮軟件模塊的組織層次、管理、重用以及工具，層次式風(fēng)格，針對(duì)編程人員和軟件

4、管理者；物理視圖將軟件映射到硬件，包含網(wǎng)絡(luò)、task以及對(duì)象映射為節(jié)點(diǎn)時(shí)的拓?fù)浣Y(jié)構(gòu)和通信，考慮與硬件相關(guān)的肺功能呢個(gè)需求，針對(duì)系統(tǒng)工程師；場(chǎng)景將上面的視圖元素組織在一起，通過(guò)一小組重要的場(chǎng)景來(lái)表現(xiàn)各視圖的工作，考慮系統(tǒng)一致性和驗(yàn)證，針對(duì)其他視圖和評(píng)估者等所有用戶。邏輯視圖：面向?qū)ο蠓纸?，系統(tǒng)將問(wèn)題域分解成一系列關(guān)鍵的抽象，以對(duì)象或類的形式表現(xiàn)。view：最終用戶consider：功能需求不僅是功能性分析，還可以識(shí)別系統(tǒng)不同部分之間共同的機(jī)制和設(shè)計(jì)元素。進(jìn)程視圖：進(jìn)程分解view：Integratorconsider：非功能需求（并發(fā)、性能、scalability）style：幾個(gè)風(fēng)格都可以滿足

5、這個(gè)視圖使用多層次的抽象，最高時(shí)進(jìn)程的邏輯網(wǎng)；系統(tǒng)被分成幾個(gè)相互獨(dú)立的任務(wù)：主要任務(wù)是體系結(jié)構(gòu)相關(guān)的任務(wù)、次要任務(wù)是幫助類的任務(wù)重點(diǎn)關(guān)注系統(tǒng)運(yùn)行起來(lái)之后的特征開(kāi)發(fā)視圖：子系統(tǒng)分解viewer：程序員和軟件經(jīng)理consider：軟件模塊組織（層次結(jié)構(gòu)、軟件管理、復(fù)用、工具約束等）style：分層風(fēng)格物理視圖：將軟件映射到硬件上viewer：系統(tǒng)集成師consider：非功能需求（可用性、可靠性（容錯(cuò)性）、性能（吞吐量）、scalcbility）場(chǎng)景：將所有放在一起viewer：其他視圖所有人和評(píng)價(jià)者consider：四個(gè)視圖間的一致性、可驗(yàn)證性體系結(jié)構(gòu)設(shè)計(jì)階段幫助架構(gòu)師；幫助解釋和驗(yàn)證文檔軟件體

6、系結(jié)構(gòu)設(shè)計(jì)決策GRASP模式（考其中之一）（創(chuàng)建模式、信息專家模式、控制者模式） HYPERLINK /sevenyuan/archive/2010/03/05/1678730.html GRASP (職責(zé)分配原則)要學(xué)習(xí)設(shè)計(jì)模式，有些基礎(chǔ)知識(shí)是我們必須要先知道的，設(shè)計(jì)模式是關(guān)于類和對(duì)象的一種高效、靈活的使用方式，也就是說(shuō)，必須先有類和對(duì)象，才能有設(shè)計(jì)模式的用武之地，否則一切都是空談，那么類和對(duì)象是從那冒出來(lái)的呢？這時(shí)就需要比23種設(shè)計(jì)模式更重要更經(jīng)典的GRASP模式登場(chǎng)了，嘿嘿，原來(lái)這才是老大！GRASP(General Responsibility Assignment Software

7、Patterns)，中文名稱為“通用職責(zé)分配軟件模式”，GRASP一共包括9種模式，它們描述了對(duì)象設(shè)計(jì)和職責(zé)分配的基本原則。也就是說(shuō)，如何把現(xiàn)實(shí)世界的業(yè)務(wù)功能抽象成對(duì)象，如何決定一個(gè)系統(tǒng)有多少對(duì)象，每個(gè)對(duì)象都包括什么職責(zé)，GRASP模式給出了最基本的指導(dǎo)原則。初學(xué)者應(yīng)該盡快掌握、理解這些原則，因?yàn)檫@是如何設(shè)計(jì)一個(gè)面向?qū)ο笙到y(tǒng)的基礎(chǔ)。可以說(shuō)，GRASP是學(xué)習(xí)使用設(shè)計(jì)模式的基礎(chǔ)。1.Information Expert (信息專家)信息專家模式是面向?qū)ο笤O(shè)計(jì)的最基本原則，是我們平時(shí)使用最多，應(yīng)該跟我們的思想融為一體的原則。也就是說(shuō)，我們?cè)O(shè)計(jì)對(duì)象(類)的時(shí)候，如果某個(gè)類擁有完成某個(gè)職責(zé)所需要的所有信

8、息，那么這個(gè)職責(zé)就應(yīng)該分配給這個(gè)類來(lái)實(shí)現(xiàn)。這時(shí)，這個(gè)類就是相對(duì)于這個(gè)職責(zé)的信息專家。例如：常見(jiàn)的網(wǎng)上商店里的購(gòu)物車(ShopCar),需要讓每種商品(SKU)只在購(gòu)物車內(nèi)出現(xiàn)一次，購(gòu)買相同商品，只需要更新商品的數(shù)量即可。如下圖：(SKUID)來(lái)唯一區(qū)分商品，而商品編號(hào)是唯一存在于商品類里的，所以根據(jù)信息專家模式，應(yīng)該把比較商品是否相同的方法放在商品類里。2.Creator (創(chuàng)造者)實(shí)際應(yīng)用中，符合下列任一條件的時(shí)候，都應(yīng)該由類來(lái)創(chuàng)建類，這時(shí)是的創(chuàng)建者：a.是的聚合b.是的容器c.持有初始化的信息(數(shù)據(jù))d.記錄的實(shí)例e.頻繁使用如果一個(gè)類創(chuàng)建了另一個(gè)類，那么這兩個(gè)類之間就有了耦合，也可以說(shuō)產(chǎn)

9、生了依賴關(guān)系。依賴或耦合本身是沒(méi)有錯(cuò)誤的，但是它們帶來(lái)的問(wèn)題就是在以后的維護(hù)中會(huì)產(chǎn)生連鎖反應(yīng)，而必要的耦合是逃不掉的，我們能做的就是正確地創(chuàng)建耦合關(guān)系，不要隨便建立類之間的依賴關(guān)系，那么該如何去做呢？就是要遵守創(chuàng)建者模式規(guī)定的基本原則，凡是不符合以上條件的情況，都不能隨便用A創(chuàng)建B。例如：因?yàn)橛唵?Order)是商品(SKU)的容器，所以應(yīng)該由訂單來(lái)創(chuàng)建商品。如下圖：3.Low coupling (低耦合)低耦合模式的意思就是要我們盡可能地減少類之間的連接。其作用非常重要：a.低耦合降低了因一個(gè)類的變化而影響其他類的范圍。b.低耦合使類更容易理解，因?yàn)轭悤?huì)變得簡(jiǎn)單，更內(nèi)聚。下面這些情況會(huì)造成類

10、A、B之間的耦合：a.A是B的屬性b.A調(diào)用B的實(shí)例的方法c.A的方法中引用了B，例如B是A方法的返回值或參數(shù)。d.A是B的子類，或者A實(shí)現(xiàn)了B關(guān)于低耦合，還有下面一些基本原則：a.Dont Talk to Strangers原則：意思就是說(shuō)，不需要通信的兩個(gè)對(duì)象之間，不要進(jìn)行無(wú)謂的連接，連接了就有可能產(chǎn)生問(wèn)題，不連接就一了百了啦！b.如果A已經(jīng)和B有連接，如果分配A的職責(zé)給B不合適的話(違反信息專家模式)，那么就把B的職責(zé)分配給A。c.兩個(gè)不同模塊的內(nèi)部類之間不能直接連接，否則必招報(bào)應(yīng)！嘿！例如：Creator模式的例子里，實(shí)際業(yè)務(wù)中需要另一個(gè)出貨人來(lái)清點(diǎn)訂單(Order)上的商品(SKU)

11、，并計(jì)算出商品的總價(jià)，但是由于訂單和商品之間的耦合已經(jīng)存在了，那么把這個(gè)職責(zé)分配給訂單更合適，這樣可以降低耦合，以便降低系統(tǒng)的復(fù)雜性。如下圖：TotalPrice()方法來(lái)執(zhí)行計(jì)算總價(jià)的職責(zé)，沒(méi)有增加不必要的耦合。4.High cohesion (高內(nèi)聚)高內(nèi)聚的意思是給類盡量分配內(nèi)聚的職責(zé)，也可以說(shuō)成是功能性內(nèi)聚的職責(zé)。即功能性緊密相關(guān)的職責(zé)應(yīng)該放在一個(gè)類里，并共同完成有限的功能，那么就是高內(nèi)聚合。這樣更有利于類的理解和重用，也便于類的維護(hù)。高內(nèi)聚也可以說(shuō)是一種隔離，就想人體由很多獨(dú)立的細(xì)胞組成，大廈由很多磚頭、鋼筋、混凝土組成，每一個(gè)部分(類)都有自己獨(dú)立的職責(zé)和特性，每一個(gè)部分內(nèi)部發(fā)生了

12、問(wèn)題，也不會(huì)影響其他部分，因?yàn)楦邇?nèi)聚的對(duì)象之間是隔離開(kāi)的。例如：一個(gè)訂單數(shù)據(jù)存取類(OrderDAO)，訂單即可以保存為Excel模式，也可以保存到數(shù)據(jù)庫(kù)中；那么，不同的職責(zé)最好由不同的類來(lái)實(shí)現(xiàn)，這樣才是高內(nèi)聚的設(shè)計(jì)，如下圖：Excel的功能發(fā)生錯(cuò)誤，那么就去檢查OrderDAOExcel類就可以了，這樣也使系統(tǒng)更模塊化，方便劃分任務(wù)，比如這兩個(gè)類就可以分配個(gè)不同的人同時(shí)進(jìn)行開(kāi)發(fā)，這樣也提高了團(tuán)隊(duì)協(xié)作和開(kāi)發(fā)進(jìn)度。5.Controller (控制器)用來(lái)接收和處理系統(tǒng)事件的職責(zé)，一般應(yīng)該分配給一個(gè)能夠代表整個(gè)系統(tǒng)的類，這樣的類通常被命名為“XX處理器”、“XX協(xié)調(diào)器”或者“XX會(huì)話”。關(guān)于控制器

13、類，有如下原則：a.系統(tǒng)事件的接收與處理通常由一個(gè)高級(jí)類來(lái)代替。b.一個(gè)子系統(tǒng)會(huì)有很多控制器類，分別處理不同的事務(wù)。關(guān)于這個(gè)模式更詳細(xì)的論述，請(qǐng)參考UML和模式應(yīng)用第16章。6.Polymorphism (多態(tài))這里的多態(tài)跟OO三大基本特征之一的“多態(tài)”是一個(gè)意思。例如：我們想設(shè)計(jì)一個(gè)繪圖程序，要支持可以畫(huà)不同類型的圖形，我們定義一個(gè)抽象類Shape,矩形(Rectangle)、圓形(Round)分別繼承這個(gè)抽象類，并重寫(override)Shape類里的Draw()方法，這樣我們就可以使用同樣的接口(Shape抽象類)繪制出不同的圖形，如下圖：(Diamond)類，對(duì)整個(gè)系統(tǒng)結(jié)構(gòu)也沒(méi)有任何

14、影響，只要增加一個(gè)繼承Shape的類就行了。7.Pure Fabrication (純虛構(gòu))這里的純虛構(gòu)跟我們常說(shuō)的純虛構(gòu)函數(shù)意思相近。高內(nèi)聚低耦合，是系統(tǒng)設(shè)計(jì)的終極目標(biāo)，但是內(nèi)聚和耦合永遠(yuǎn)都是矛盾對(duì)立的。高內(nèi)聚以為這拆分出更多數(shù)量的類，但是對(duì)象之間需要協(xié)作來(lái)完成任務(wù)，這又造成了高耦合，反過(guò)來(lái)毅然。該如何解決這個(gè)矛盾呢，這個(gè)時(shí)候就需要純虛構(gòu)模式，由一個(gè)純虛構(gòu)的類來(lái)協(xié)調(diào)內(nèi)聚和耦合，可以在一定程度上解決上述問(wèn)題。例如：上面多態(tài)模式的例子，如果我們的繪圖程序需要支持不同的系統(tǒng)，那么因?yàn)椴煌到y(tǒng)的API結(jié)構(gòu)不同，繪圖功能也需要不同的實(shí)現(xiàn)方式，那么該如何設(shè)計(jì)更合適呢？如下圖：AbstractShape，

15、不論是哪個(gè)系統(tǒng)都可以通過(guò)AbstractShape類來(lái)繪制圖形，我們即沒(méi)有降低原來(lái)的內(nèi)聚性，也沒(méi)有增加過(guò)多的耦合，可謂魚(yú)肉和熊掌兼得，哈哈哈！ 8.Indirection (間接)“間接”顧名思義，就是這個(gè)事不能直接來(lái)辦，需要繞個(gè)彎才行。繞個(gè)彎的好處就是，本來(lái)直接會(huì)連接在一起的對(duì)象彼此隔離開(kāi)了，一個(gè)的變動(dòng)不會(huì)影響另一個(gè)。就想我在前面的低耦合模式里說(shuō)的一樣，“兩個(gè)不同模塊的內(nèi)部類之間不能直接連接”，但是我們可以通過(guò)中間類來(lái)間接連接兩個(gè)不同的模塊，這樣對(duì)于這兩個(gè)模塊來(lái)說(shuō)，他們之間仍然是沒(méi)有耦合/依賴關(guān)系的。9.Protected Variations (受保護(hù)變化)預(yù)先找出不穩(wěn)定的變化點(diǎn)，使用統(tǒng)一

16、的接口封裝起來(lái)，如果未來(lái)發(fā)生變化的時(shí)候，可以通過(guò)接口擴(kuò)展新的功能，而不需要去修改原來(lái)舊的實(shí)現(xiàn)。也可以把這個(gè)模式理解為OCP(開(kāi)閉原則)原則，就是說(shuō)一個(gè)軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開(kāi)發(fā)，對(duì)修改關(guān)閉。在設(shè)計(jì)一個(gè)模塊的時(shí)候，要保證這個(gè)模塊可以在不需要被修改的前提下可以得到擴(kuò)展。這樣做的好處就是通過(guò)擴(kuò)展給系統(tǒng)提供了新的職責(zé)，以滿足新的需求，同時(shí)又沒(méi)有改變系統(tǒng)原來(lái)的功能。關(guān)于OCP原則，后面還會(huì)有單獨(dú)的論述。這里我們可以看到，因?yàn)樵黾恿思兲摌?gòu)類這樣的設(shè)計(jì)更符合高內(nèi)聚和低耦合原則，雖然后來(lái)我們又增加了一個(gè)菱形這里我們把兩種不同的數(shù)據(jù)存儲(chǔ)功能分別放在了兩個(gè)類里來(lái)實(shí)現(xiàn)，這樣如果未來(lái)保存到這里我們?cè)谟唵晤惱镌黾恿艘粋€(gè)這里

17、因?yàn)橛唵问巧唐返娜萜鳎仓挥杏唵纬钟谐跏蓟唐返男畔?，所以這個(gè)耦合關(guān)系是正確的且沒(méi)辦法避免的，所以由訂單來(lái)創(chuàng)建商品。針對(duì)這個(gè)問(wèn)題需要權(quán)衡的是，比較商品是否相同的方法需要放到那里類里來(lái)實(shí)現(xiàn)呢？分析業(yè)務(wù)得知需要根據(jù)商品的編號(hào)我們生活在一個(gè)充滿規(guī)則的世界里，在復(fù)雜多變的外表下，萬(wàn)事萬(wàn)物都被永恒的真理支配并有規(guī)律的運(yùn)行著。模式也是一樣，不論那種模式，其背后都潛藏著一些“永恒的真理”，這個(gè)真理就是設(shè)計(jì)原則。記得一次參加微軟的架構(gòu)師培訓(xùn)，期間講到設(shè)計(jì)模式，有人問(wèn)了老師一個(gè)問(wèn)題：“什么東西比設(shè)計(jì)模式更重要？”，老師是一位有多年豐富實(shí)踐經(jīng)驗(yàn)的開(kāi)發(fā)者，他毫不猶豫地回答到：“比模式更重要的是原則”。這句話我時(shí)常能

18、夠想起，越來(lái)越覺(jué)得這是一個(gè)偉大的答案。的確，還有什么比原則更重要呢？就像人的世界觀和人生觀一樣，那才是支配你一切行為的根本，而對(duì)于設(shè)計(jì)模式來(lái)說(shuō)，為什么這個(gè)模式要這樣解決這個(gè)問(wèn)題，而另一個(gè)模式要那樣，它們背后都遵循的就是永恒的設(shè)計(jì)原則?？梢哉f(shuō)，設(shè)計(jì)原則是設(shè)計(jì)模式的靈魂。對(duì)于設(shè)計(jì)原則的深入探討我還沒(méi)有那個(gè)深度，推薦大家去看敏捷軟件開(kāi)發(fā)原則、模式與實(shí)踐，下面僅對(duì)部分常用的設(shè)計(jì)原則做些簡(jiǎn)單的講解： 1.單一職責(zé)原則(SRP)“就一個(gè)類而言，應(yīng)該僅有一個(gè)引起它變化的原因?！币簿褪钦f(shuō)，不要把變化原因各不相同的職責(zé)放在一起，因?yàn)椴煌淖兓瘯?huì)影響到不相干的職責(zé)。再通俗一點(diǎn)地說(shuō)就是，不該你管的事情你不要管，管好

19、自己的事情就可以了，多管閑事害了自己也害了別人。(當(dāng)然這里說(shuō)的多管閑事跟見(jiàn)義勇為是兩回事，我們提倡見(jiàn)義勇為！)例如：參考下圖中的設(shè)計(jì)，圖形計(jì)算程序只使用了正方形的Area()方法，永遠(yuǎn)不會(huì)使用Draw()方法，而它卻跟Draw方法關(guān)聯(lián)了起來(lái)。這違反了單一原則，如果未來(lái)因?yàn)閳D形繪制程序?qū)е翫raw()方法產(chǎn)生了變化，那么就會(huì)影響到本來(lái)毫不關(guān)系的圖形計(jì)算程序。 那么我們?cè)撛趺醋瞿?？如下圖，將不同的職責(zé)分配給不同的類，使單個(gè)類的職責(zé)盡量單一，就隔離了變化，這樣他們也不會(huì)互相影響了。分類: HYPERLINK /sevenyuan/category/219509.html 設(shè)計(jì)模式通用職責(zé)分配軟件模式

20、(GRASP)側(cè)重于基本的通用設(shè)計(jì)過(guò)程，是針對(duì)FURPS+需求模型中的Functional(功能性）的重要的設(shè)計(jì)原則。 GoF設(shè)計(jì)模式更注重FURPS+需求模型中的質(zhì)量需求的設(shè)計(jì)。 可以在GoF設(shè)計(jì)模式中找到GRASP的影子。個(gè)人的一點(diǎn)小經(jīng)驗(yàn)：1、解決接口變化的外部服務(wù)問(wèn)題時(shí)使用“適配器模式-工廠模式（創(chuàng)建適配器）-Singleton模式（使全局可見(jiàn)）”.2、解決變化的算法及策略問(wèn)題時(shí)（客戶定制業(yè)務(wù)規(guī)則）使用“策略模式（將不同算法定義為實(shí)現(xiàn)同一接口的獨(dú)立類）-工廠模式（創(chuàng)建策略對(duì)象）-Singleton模式（可選）”,并可以加入組合模式來(lái)解決策略的沖突。3、使用觀察者模式降低表示層與業(yè)務(wù)層的耦

21、合。模式名稱描述（問(wèn)題/解決方案)信息專家模式問(wèn)題：對(duì)象設(shè)計(jì)和職責(zé)分配的一般原則是什么？解決方案：將職責(zé)分配給擁有履行一個(gè)職責(zé)所必需信息的類即信息專家。（也就是將職責(zé)分配給一個(gè)類，這個(gè)類必須擁有履行這個(gè)職責(zé)所需要的信息。）創(chuàng)建者模式問(wèn)題：誰(shuí)應(yīng)該負(fù)責(zé)產(chǎn)生類的實(shí)例（對(duì)應(yīng)于GoF設(shè)計(jì)模式系列里的“工廠模式”）解決方案：如果符合下面的一個(gè)或多個(gè)條件，則將創(chuàng)建類A實(shí)例的職責(zé)分配給類B.類B聚合類A的對(duì)象。.類B包含類A的對(duì)象。.類B記錄類A對(duì)象的實(shí)例。.類B密切使用類A的對(duì)象。.類B初始化數(shù)據(jù)并在創(chuàng)建類A的實(shí)例時(shí)傳遞給類A（類B是創(chuàng)建類A實(shí)例的一個(gè)專家)。在以上情況下，類B是類A對(duì)象的創(chuàng)建者?？刂破髂Ｊ?/p>

22、問(wèn)題：誰(shuí)處理一個(gè)系統(tǒng)事件？解決方案：當(dāng)類代表下列一種情況時(shí)，為它分配處理系統(tǒng)事件消息的職責(zé)。.代表整個(gè)系統(tǒng)、設(shè)備或子系統(tǒng)（外觀控制器）。.代表系統(tǒng)事件發(fā)生的用例場(chǎng)景（用例或回話控制器）。低耦合問(wèn)題：如何支持低依賴性以及增加重用性？解決方案：分配職責(zé)時(shí)使（不必要的）耦合保持為最低。高內(nèi)聚問(wèn)題：如何讓復(fù)雜性可管理？解決方案：分配職責(zé)時(shí)使內(nèi)聚保持為最高。多態(tài)模式問(wèn)題：當(dāng)行為隨類型變化而變化時(shí)誰(shuí)來(lái)負(fù)責(zé)處理這些變化？解決方案：當(dāng)類型變化導(dǎo)致另一個(gè)行為或?qū)е滦袨樽兓瘯r(shí)，應(yīng)用多態(tài)操作將行為的職責(zé)分配到引起行為變化的類型。純虛構(gòu)模式問(wèn)題：當(dāng)不想破壞高內(nèi)聚和低耦合的設(shè)計(jì)原則時(shí)，誰(shuí)來(lái)負(fù)責(zé)處理這些變化？解決方案：將

23、一組高內(nèi)聚的職責(zé)分配給一個(gè)虛構(gòu)的或處理方便的“行為”類，它并不是問(wèn)題域中的概念，而是虛構(gòu)的事務(wù)，以達(dá)到支持高內(nèi)聚、低耦合和重用的目的。中介模式問(wèn)題：如何分配職責(zé)以避免直接耦合？解決方案：分配職責(zé)給中間對(duì)象以協(xié)調(diào)組件或服務(wù)之間的操作，使得它們不直接耦合。受保護(hù)變化模式問(wèn)題：如何分配職責(zé)給對(duì)象、子系統(tǒng)和系統(tǒng)，使得這些元素中的變化或不穩(wěn)定的點(diǎn)不會(huì)對(duì)其他元素產(chǎn)生不利影響？解決方案：找出預(yù)計(jì)有變化或不穩(wěn)定的元素，為其創(chuàng)建穩(wěn)定的“接口”而分配職責(zé)。對(duì)給定場(chǎng)景，判斷職責(zé)的分配。（通常給一個(gè)系統(tǒng)順序圖，每個(gè)箭頭都是一個(gè)職責(zé)，每個(gè)職責(zé)怎么分配，職責(zé)通常需要分解，怎么分解看上課例子）高聚合，低耦合 面向?qū)ο蟮淖罡?/p>

24、原則！多態(tài) Adapter, Command, Composite, Proxy, State, and Strategy模式其實(shí)都使用多態(tài)來(lái)實(shí)現(xiàn)。純虛構(gòu)行為對(duì)象，功能為中心的對(duì)象。Adapter, Strategy, Command都是這一模式的具體實(shí)現(xiàn)。間接性計(jì)通過(guò)引入中間層加以解決 ；Adapter, Bridge, Facade, Observer, Mediator，都是具體實(shí)現(xiàn)。 差異性保護(hù)隔離封裝變化。將變化，不確定的東西用穩(wěn)定不變的接口封裝隔離保護(hù)起來(lái)。信息隱藏 和 開(kāi)閉原則具有相同的含義模式名稱問(wèn)題，解決方案，優(yōu)缺點(diǎn)信息專家模式問(wèn)題：對(duì)象設(shè)計(jì)和職責(zé)分配的一般原則是什么？解決方

25、案：將職責(zé)分配給擁有履行一個(gè)職責(zé)所必需信息的類即信息專家。（也就是將職責(zé)分配給一個(gè)類，這個(gè)類必須擁有履行這個(gè)職責(zé)所需要的信息。）優(yōu)點(diǎn)：維護(hù)信息影藏，支持高內(nèi)聚低耦合，缺點(diǎn)：讓類變得復(fù)雜創(chuàng)建者模式問(wèn)題：誰(shuí)應(yīng)該負(fù)責(zé)產(chǎn)生類的實(shí)例（對(duì)應(yīng)于GoF設(shè)計(jì)模式系列里的“工廠模式”）解決方案：如果符合下面的一個(gè)或多個(gè)條件，則將創(chuàng)建類A實(shí)例的職責(zé)分配給類B.類B聚合類A的對(duì)象。（prefer）.類B包含類A的對(duì)象。（prefer）.類B記錄類A對(duì)象的實(shí)例。.類B密切使用類A的對(duì)象。.類B初始化數(shù)據(jù)并在創(chuàng)建類A的實(shí)例時(shí)傳遞給類A（類B是創(chuàng)建類A實(shí)例的一個(gè)專家)。在以上情況下，類B是類A對(duì)象的創(chuàng)建者。優(yōu)點(diǎn)：支持低耦合

26、：將創(chuàng)建實(shí)例的職責(zé)分配給需要對(duì)象引用的類 降低依賴：通過(guò)自己創(chuàng)建對(duì)象避免了依賴其它類幫他們創(chuàng)建對(duì)象控制器模式問(wèn)題：誰(shuí)處理一個(gè)系統(tǒng)事件？解決方案：當(dāng)類代表下列一種情況時(shí)，為它分配處理系統(tǒng)事件消息的職責(zé)。.代表整個(gè)系統(tǒng)、設(shè)備或子系統(tǒng)（外觀控制器）。.代表系統(tǒng)事件發(fā)生的用例場(chǎng)景（用例或回話控制器）。 專門設(shè)計(jì)一個(gè)類處理事件：1（功能）針對(duì)業(yè)務(wù) 或overall organization(a faade controller).（集中式） 2（系統(tǒng)）針對(duì)系統(tǒng) (a faade controller).（集中式） 3（角色）針對(duì)模塊 （a role controller）（近似集中式）4（用例）針對(duì)一個(gè)

27、用例 (a use case controller)（近似分散式）優(yōu)點(diǎn)：使外部事件源和內(nèi)部事件處理器不相互依賴對(duì)方的類型和行為 缺點(diǎn)：？The controller objects can become highly coupled and uncohesive with more responsiblities （不是很懂）低耦合問(wèn)題：如何支持低依賴性以及增加重用性？解決方案：分配職責(zé)時(shí)使（不必要的）耦合保持為最低。OO中耦合的種類：Y是X的屬性X的方法中有Y（參數(shù)，局部變量，返回值）X是Y的子孫類X實(shí)現(xiàn)Y接口優(yōu)點(diǎn)：類更易維護(hù)，易復(fù)用，將change本地化高內(nèi)聚問(wèn)題：如何讓復(fù)雜性可管理？解決

28、方案：分配職責(zé)時(shí)使內(nèi)聚保持為最高。內(nèi)聚的不同程度：非常低內(nèi)聚:一個(gè)類的職責(zé)包括很多功能低內(nèi)聚: 一個(gè)類職責(zé)包含一個(gè)功能中的復(fù)雜的任務(wù)高內(nèi)聚. 一個(gè)類在一個(gè)功能上有適中的職責(zé)，和其他類協(xié)作完成任務(wù)。 優(yōu)點(diǎn)：類易維護(hù)，易理解，支持低耦合，支持復(fù)用多態(tài)模式問(wèn)題：當(dāng)行為隨類型變化而變化時(shí)誰(shuí)來(lái)負(fù)責(zé)處理這些變化？解決方案：當(dāng)類型變化導(dǎo)致另一個(gè)行為或?qū)е滦袨樽兓瘯r(shí)，應(yīng)用多態(tài)操作將行為的職責(zé)分配到引起行為變化的類型。優(yōu)點(diǎn)：更簡(jiǎn)單可靠，對(duì)比復(fù)雜的選擇邏輯（判斷語(yǔ)句）更易添加額外的行為在設(shè)計(jì)中增加類的數(shù)量使代碼更易理解純虛構(gòu)模式問(wèn)題：當(dāng)不想破壞高內(nèi)聚和低耦合的設(shè)計(jì)原則時(shí)，誰(shuí)來(lái)負(fù)責(zé)處理這些變化？解決方案：將一組高內(nèi)

29、聚的職責(zé)分配給一個(gè)虛構(gòu)的或處理方便的“行為”類，它并不是問(wèn)題域中的概念，而是虛構(gòu)的事務(wù)，以達(dá)到支持高內(nèi)聚、低耦合和重用的目的。典型適用場(chǎng)景：將representation 從 model中分離出去將platforms(facilities) 從 model中分離出去分離復(fù)雜的行為分離復(fù)雜的數(shù)據(jù)結(jié)構(gòu)優(yōu)點(diǎn)：支持高內(nèi)聚：相關(guān)職責(zé)被封裝成一個(gè)類來(lái)處理一系列相關(guān)任務(wù)。 支持復(fù)用because of the presence of fine grained Pure Fabrication classes. 間接性問(wèn)題：如何分配職責(zé)以避免直接耦合？解決方案：分配職責(zé)給中間對(duì)象以協(xié)調(diào)組件或服務(wù)之間的操作，使

30、得它們不直接耦合。優(yōu)點(diǎn)：與可變性低耦合，支持復(fù)用受保護(hù)變化模式問(wèn)題：如何分配職責(zé)給對(duì)象、子系統(tǒng)和系統(tǒng)，使得這些元素中的變化或不穩(wěn)定的點(diǎn)不會(huì)對(duì)其他元素產(chǎn)生不利影響？解決方案：找出預(yù)計(jì)有變化或不穩(wěn)定的元素，為其創(chuàng)建穩(wěn)定的“接口”而分配職責(zé)。類型：Information HidingData driven (configuration files)Service lookup (runtime registration)Interpreter-Driven(generalize module)Reflective or Meta-Level Designs (Component replace)Un

31、iform Access (adherence to protocols)LSP (polymorphism)Law of Demeter (restrict communication paths) GRASP模式（或其中之一）： General Responsibility Assignment Software patterns（通用職責(zé)軟件模式），核心思想是職責(zé)分配，用職責(zé)設(shè)計(jì)對(duì)象。主要特征：對(duì)象職責(zé)分配的基本原則；主要應(yīng)用在分析和建模上。核心思想理解：自己干自己的事（職責(zé)的分配）；自己干自己的能干的事（職責(zé)的分配）；自己只干自己的事（職責(zé)的內(nèi)聚）；包含9個(gè)基本模式：1 信息專家：解決

32、類的職責(zé)分配問(wèn)題的最基本模式。問(wèn)題：當(dāng)我們發(fā)現(xiàn)完對(duì)對(duì)象和職責(zé)后，職責(zé)的分配原則是什么？解決方案：職責(zé)的執(zhí)行需要某些信息，把職責(zé)分配給該信息的擁有者。即某項(xiàng)職責(zé)的執(zhí)行需要某些資源，只有擁有這些資源的對(duì)象才有資格執(zhí)行職責(zé)。優(yōu)點(diǎn)：信息擁有者類同時(shí)就是信息的操作類，可以減少不必要的類之間的關(guān)聯(lián)；各個(gè)類的職責(zé)單一明確，容易理解；保持信息的封裝性；促進(jìn)低耦合和高內(nèi)聚；造成某個(gè)類過(guò)于復(fù)雜。2 創(chuàng)建者：解決類的實(shí)例和創(chuàng)建職責(zé)問(wèn)題的模式。問(wèn)題：類的實(shí)例的創(chuàng)建職責(zé)，應(yīng)該分配給什么樣的類？或者說(shuō)類的實(shí)例應(yīng)該由誰(shuí)來(lái)創(chuàng)建？解決方案：B包含A，或B聚集A，或B記錄A，或B頻繁使用A或B有A初始化數(shù)據(jù)時(shí)，類A的實(shí)例的創(chuàng)建職

33、責(zé)就分配給B。（其中，最提倡聚集和包含）一般用工廠模式或抽象工廠模式作為替代方案。優(yōu)點(diǎn)：整個(gè)結(jié)構(gòu)清晰易懂；有利于類或組件的重用；防止職責(zé)的分散；降低耦合性。避免依賴其他的類來(lái)創(chuàng)建自己的對(duì)象。3 高內(nèi)聚：為降低類的復(fù)雜程度，簡(jiǎn)化控制而提出的面向?qū)ο笤O(shè)計(jì)的原則性模式。（其他模式的根本）問(wèn)題：怎么做才能降低類的復(fù)雜程度，簡(jiǎn)化控制？解決方案：緊密相關(guān)的功能（職責(zé)）應(yīng)該分配給同一個(gè)類。優(yōu)點(diǎn)：聚集相關(guān)功能，結(jié)構(gòu)清晰，容易理解；只聚集相關(guān)功能，使得類的職責(zé)單一明確，從而降低類的復(fù)雜程度，使用簡(jiǎn)單。類易于維護(hù)；支持低耦合；支持復(fù)用。4 低耦合：為降低類之間的關(guān)聯(lián)程度，適應(yīng)可變性而提出的面向?qū)ο笤O(shè)計(jì)的原則性模式

34、。（其他模式的根本）問(wèn)題：怎樣做才能降低類之間關(guān)聯(lián)程度，適應(yīng)需求的變化呢？解決方案：為類分配職責(zé)時(shí)，應(yīng)該盡量降低類之間的關(guān)聯(lián)關(guān)系（耦合性）。亦即，應(yīng)該以降低類之間的耦合關(guān)系作為職責(zé)分配的原則。優(yōu)點(diǎn)：獨(dú)立性，有利于重用和維護(hù)；適應(yīng)需求變化，一旦發(fā)生變化時(shí)，可以把影響范圍縮小到最小范圍。5 控制器：解決事件處理職責(zé)問(wèn)題的模式。問(wèn)題：在UI層之外，應(yīng)該由哪個(gè)類來(lái)處理（控制）系統(tǒng)操作（事件）呢？解決方案：把系統(tǒng)事件的處理職責(zé)分配給控制器類。擔(dān)當(dāng)控制器類角色的候補(bǔ)類可能為：系統(tǒng)全體，設(shè)備，子系統(tǒng)等的表現(xiàn)類（Faade Controller）；系統(tǒng)實(shí)踐發(fā)生的用例的控制類，通常被命名為Handler，Coo

35、rdinator，Session等。優(yōu)點(diǎn)：防止同類職責(zé)的分散。滿足高內(nèi)聚，低耦合原則；有利于共通處理；變化的高適應(yīng)能力，能把變化的修改范圍控制在最小范圍內(nèi)。增加復(fù)用的潛力，基本思想是控制器對(duì)象使外部事件源和內(nèi)部事件處理的類型和行為相互獨(dú)立（解耦）；隨時(shí)查看用例的狀態(tài)，保證系統(tǒng)操作的合法性，或解釋當(dāng)前活動(dòng)或操作的狀態(tài)。6 多態(tài)性：擴(kuò)展模式的一種，通過(guò)多態(tài)操作把基于類型的可變行為的定義職責(zé)分配給行為發(fā)生的類。（命令模式、策略模式、依賴倒置原則）問(wèn)題：根據(jù)類型（類）的不同而發(fā)生變化的行為的定義，應(yīng)該分配給誰(shuí)？解決方案：提倡通過(guò)多臺(tái)操作把基于類型的可變行為的定義職責(zé)分配給行為發(fā)生的類。繼承有三種：父類

36、型子類型（類型多態(tài)）處理差異性（行為多態(tài)）為了復(fù)用（效果多態(tài)）優(yōu)點(diǎn)：避免重復(fù)代碼；避免重復(fù)的分歧條件；易擴(kuò)展，只要實(shí)現(xiàn)了統(tǒng)一的通用接口，便可實(shí)現(xiàn)行為的擴(kuò)展。比顯示的選擇邏輯更為簡(jiǎn)單和可靠；在設(shè)計(jì)中增加類的數(shù)量；會(huì)使代碼不易追蹤；把多個(gè)耦合變?yōu)橐粋€(gè)耦合。7 純虛構(gòu)：擴(kuò)展模式之一，把非問(wèn)題領(lǐng)域中的職責(zé)分配給人工定義的類，問(wèn)題：非問(wèn)題領(lǐng)域中的職責(zé)應(yīng)該分配給誰(shuí)？或者說(shuō)，按照信息專家等模式分配職責(zé)時(shí)，存在某些不恰當(dāng)?shù)穆氊?zé)時(shí)，應(yīng)該怎么做？解決方案：提倡把那些非問(wèn)題領(lǐng)域的職責(zé)分配給那些人工生成的或者容易此類職責(zé)的概念類?？梢灾挥行袨闆](méi)有狀態(tài)或只有狀態(tài)沒(méi)有行為。優(yōu)點(diǎn)：高內(nèi)聚，不必分配問(wèn)題領(lǐng)域以外的職責(zé)給Dom

37、ain類，從而保證各Domain類內(nèi)部功能上的高度聚集性；低耦合，問(wèn)題領(lǐng)域以外的職責(zé)被分配給第三方非Domain類，一方面可以降低各Domain類之間的關(guān)聯(lián)程度，另一方面可以比較漂亮地整合系統(tǒng)的各方面的職責(zé)；重用性，各Domain類由于功能上的聚集和關(guān)聯(lián)度的降低，可以更容易地得到重用。8 間接模式：解決類的關(guān)聯(lián)問(wèn)題的模式。問(wèn)題：為了避免類之間的直接關(guān)聯(lián)，應(yīng)該給什么樣的類分配“關(guān)聯(lián)”責(zé)任？解決方案：當(dāng)多個(gè)類之間存在復(fù)雜的消息交互時(shí)，間接模式提倡類之間不直接進(jìn)行消息交互處理，而是導(dǎo)入第三方類，把責(zé)任（多個(gè)類之間的關(guān)聯(lián)責(zé)任）分配給第三方類，降低類之間的耦合程度。（中介者模式）優(yōu)點(diǎn)：高內(nèi)聚，通過(guò)把“關(guān)

38、聯(lián)”的功能分散到第三方類，原來(lái)的類可以更加關(guān)注自身功能的實(shí)現(xiàn)；低耦合，原本關(guān)聯(lián)類之間不直接關(guān)聯(lián)，降低類之間的耦合性；高重用性，第三方類對(duì)“關(guān)聯(lián)”功能的集中處理，與原來(lái)的類對(duì)自身功能的專注，有利于類的重用。9 差異性保護(hù)：擴(kuò)展模式之一，它設(shè)計(jì)穩(wěn)定的接口應(yīng)對(duì)將來(lái)可能發(fā)生的變化或其他不安定的因素。問(wèn)題：對(duì)存在于系統(tǒng)，子系統(tǒng)，或?qū)ο蟮仍刂械母鞣N變化或不安定的因素，為了不產(chǎn)生對(duì)其他元素的不利影響，在它們中間該怎樣分配職責(zé)？解決方案：提倡在可預(yù)測(cè)的變化或不安定因素的周圍，用穩(wěn)定的接口來(lái)承擔(dān)職責(zé)。優(yōu)點(diǎn)：提高系統(tǒng)對(duì)變化的應(yīng)對(duì)能力。一旦系統(tǒng)的可預(yù)見(jiàn)的不安定因素發(fā)生變化（比如追加功能等），只需要生成一個(gè)已有的穩(wěn)

39、定接口的實(shí)現(xiàn)類就可以了，無(wú)需修改原來(lái)的類；高內(nèi)聚。具體的功能在各子類中實(shí)現(xiàn)，各類的內(nèi)部功能具有高度聚集性；低耦合。用戶類只跟穩(wěn)定接口通信，減少了跟其它陌生對(duì)象的關(guān)聯(lián)的機(jī)會(huì)，降低了類之間的耦合性。軟件設(shè)計(jì)的審美標(biāo)準(zhǔn)有哪些？列舉已知的軟件設(shè)計(jì)方法與技術(shù)（至少5種）并說(shuō)明它們促進(jìn)了哪些審美標(biāo)準(zhǔn)的達(dá)成？（第一章）（模塊化、信息隱藏、design pattern、人機(jī)交互、軟件復(fù)用等促進(jìn)了哪些審美標(biāo)準(zhǔn)）（設(shè)計(jì)模式）軟件設(shè)計(jì)的審美標(biāo)準(zhǔn)有哪些簡(jiǎn)潔性：模塊化一致性（概念完整性）：體系結(jié)構(gòu)的風(fēng)格，模塊化堅(jiān)固性（高質(zhì)量）：最重要的是體現(xiàn)在體系結(jié)構(gòu)上，設(shè)計(jì)模式所要解決的問(wèn)題，模塊化易復(fù)用易修改易讀易理解易維護(hù)可靠性

40、 (availability 可以正常工作, reliability 故障和故障修復(fù))性能，質(zhì)量相關(guān)易開(kāi)發(fā)他們促進(jìn)了那些審美標(biāo)準(zhǔn)的達(dá)成模塊化：促進(jìn)了結(jié)構(gòu)一致性，堅(jiān)固性（易維護(hù)，易復(fù)用等），促進(jìn)了簡(jiǎn)潔性信息隱藏：促進(jìn)了簡(jiǎn)潔性，堅(jiān)固性（易維護(hù)，易復(fù)用），破壞了簡(jiǎn)潔性設(shè)計(jì)模式：促進(jìn)了堅(jiān)固性（易復(fù)用，易維護(hù)等等），一致性？體系結(jié)構(gòu)風(fēng)格：促進(jìn)了一致性，堅(jiān)固性職責(zé)分配（GRASP）：促進(jìn)了堅(jiān)固性，一致性協(xié)作設(shè)計(jì)：促進(jìn)了堅(jiān)固性，一致性？設(shè)計(jì)的層次性（第二章）高層設(shè)計(jì)、中層設(shè)計(jì)和低層設(shè)計(jì)各自的出發(fā)點(diǎn)、主要關(guān)注因素（即哪些審美要素）、主要方法與技術(shù)和最終制品（2和3會(huì)出一題）低層設(shè)計(jì)（代碼設(shè)計(jì)）出發(fā)點(diǎn)：程序語(yǔ)言

41、所提供的數(shù)據(jù)結(jié)構(gòu)等東西太少了為了解決類型的適配的問(wèn)題將基本的語(yǔ)言單位（類型與語(yǔ)句），組織起來(lái)，建立高質(zhì)量的 數(shù)據(jù)結(jié)構(gòu)+算法 屏蔽程序中復(fù)雜數(shù)據(jù)結(jié)構(gòu)與算法的實(shí)現(xiàn)細(xì)節(jié)對(duì)一個(gè)方法/函數(shù)的內(nèi)部代碼進(jìn)行設(shè)計(jì) 關(guān)注點(diǎn)：質(zhì)量：數(shù)據(jù)結(jié)構(gòu)合理易用，算法可靠、高效、易讀 評(píng)價(jià)：易讀，易維護(hù)簡(jiǎn)潔性部分堅(jiān)固性，包括堅(jiān)固性的，易讀，易維護(hù)，數(shù)據(jù)結(jié)構(gòu)易用，算法可靠、易讀主要技術(shù)：防御式編程Defensive Programming斷言式編程Assertive programmingDesign-by-Contract測(cè)試驅(qū)動(dòng)開(kāi)發(fā)Test-Driven programming異常處理Error handling, exce

42、ption handling配置式編程Configuring Programming表驅(qū)動(dòng)編程Table-driven Programming基于狀態(tài)機(jī)編程State-machine based Programming前面四個(gè)是關(guān)于可靠性的，后面三個(gè)是關(guān)于數(shù)據(jù)結(jié)構(gòu)帶來(lái)易讀性內(nèi)部結(jié)構(gòu)是算法和數(shù)據(jù)類型，外在表現(xiàn)是抽象數(shù)據(jù)類型最終制品：源程序，中層，底層共享了詳細(xì)設(shè)計(jì)文檔中層設(shè)計(jì)（模塊與類結(jié)構(gòu)設(shè)計(jì)）出發(fā)點(diǎn)：模塊劃分 將系統(tǒng)分成簡(jiǎn)單片段 片段有名字，可以被反復(fù)使用 名字和使用方法稱為模塊的抽象與接口 模塊內(nèi)部的程序片段為精華與實(shí)現(xiàn) 模塊劃分隱藏一些程序片段（數(shù)據(jù)結(jié)構(gòu)+算法）的細(xì)節(jié)，暴露接口于外界 關(guān)注

43、點(diǎn)：簡(jiǎn)潔性（易開(kāi)發(fā)，易修改，易復(fù)用）可觀察性看上去“顯然是正確的”（易開(kāi)發(fā)，易調(diào)試，易復(fù)用）目標(biāo)完全獨(dú)立理解 使用與復(fù)用 開(kāi)發(fā) 修改 評(píng)價(jià)質(zhì)量標(biāo)準(zhǔn)：模塊化信息隱藏OO設(shè)計(jì)原則 問(wèn)題困難：程序片段不可能完全獨(dú)立方法：實(shí)現(xiàn)盡可能的獨(dú)立（低耦合，高內(nèi)聚）模塊化信息隱藏面向?qū)ο笞罱K制品：類和模塊高層設(shè)計(jì)（體系結(jié)構(gòu)）出發(fā)點(diǎn)：主要為了解決整體功能組織的問(wèn)題組織的時(shí)候設(shè)計(jì)和功能大型軟件開(kāi)發(fā)的一個(gè)根本不同是它更關(guān)注如何將大批獨(dú)立模塊組織形成一個(gè)“系統(tǒng)”，也就是說(shuō)更重視系統(tǒng)的總體組織 關(guān)注點(diǎn):總體結(jié)構(gòu) 質(zhì)量屬性 方法：場(chǎng)景驅(qū)動(dòng)體系結(jié)構(gòu)風(fēng)格為什么要高層設(shè)計(jì):名稱匹配, 導(dǎo)入導(dǎo)出（問(wèn)題）Inside 接口（獨(dú)立，區(qū)

44、別對(duì)待）詳細(xì)設(shè)計(jì)的不足載體適配（無(wú)法描述可靠性，性能）無(wú)法實(shí)現(xiàn)交互信息本地化（信息隱藏的局限性）無(wú)法有效抽象部件的整體特性接口定義缺乏結(jié)構(gòu)性（交互的規(guī)則，如果A調(diào)用是B必須調(diào)用）不能有效適應(yīng)大型軟件的特殊開(kāi)發(fā)方法最終制品：體系結(jié)構(gòu)的設(shè)計(jì)軟件體系結(jié)構(gòu)風(fēng)格 （背誦）理解體系結(jié)構(gòu)包括三層次：高層結(jié)構(gòu)、關(guān)注點(diǎn)（質(zhì)量）、重要的設(shè)計(jì)決策。描述或比較相關(guān)風(fēng)格對(duì)給定場(chǎng)景，判斷需要使用的風(fēng)格軟件體系結(jié)構(gòu)風(fēng)格定義：用結(jié)構(gòu)化組織的模式來(lái)定義一系列系統(tǒng)，并定義組件和連接件的vocabulary以及其如何結(jié)合的限制；描述一類體系結(jié)構(gòu)或重要的體系結(jié)構(gòu)片段，實(shí)踐過(guò)程中被重復(fù)發(fā)現(xiàn)，是一組緊密相關(guān)的設(shè)計(jì)決策，具有允許重用的已知

45、屬性不同組件的風(fēng)格：對(duì)象（設(shè)計(jì)模式）、模塊、進(jìn)程、物理單元模塊風(fēng)格：進(jì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è)組件接受父組件的控制；組件是過(guò)程、函數(shù)或者模塊，連接件是他們之間的調(diào)用，限制是控制始于調(diào)用層次的頂層然后向下移動(dòng)；過(guò)程清晰易于理解，正確性控制強(qiáng)，變更和復(fù)用困難，可能是公共耦合，適用順行系統(tǒng)和正確性攸關(guān)系統(tǒng)Object-oriented（數(shù)據(jù)抽象

46、）：通過(guò)封裝數(shù)據(jù)表示和相關(guān)的操作幫助提高修改性，對(duì)象保證自己數(shù)據(jù)表示的完整性，每個(gè)對(duì)象都是匿名的代理，只能通過(guò)固定格式的過(guò)程調(diào)用來(lái)使用對(duì)象；組件是對(duì)象或模塊，連接件是函數(shù)或調(diào)用；在不影響使用者的情況下可以修改實(shí)現(xiàn)，系統(tǒng)分解為一系列匿名代理，但一個(gè)對(duì)象要與另一個(gè)對(duì)象交互必須知道對(duì)方的標(biāo)識(shí)符，并且會(huì)有副作用問(wèn)題，從而產(chǎn)生不可預(yù)期的操作，適用于有一個(gè)中心問(wèn)題并須保護(hù)相關(guān)信息（數(shù)據(jù)）的應(yīng)用Pipe and Filter：每個(gè)過(guò)濾器處理數(shù)據(jù)然后傳遞給下一個(gè)過(guò)濾器，每當(dāng)有數(shù)據(jù)需要處理時(shí)過(guò)濾器都會(huì)運(yùn)行，數(shù)據(jù)共享嚴(yán)格控制在管道的傳遞上；組件是過(guò)濾器，連接件是管道，限制是過(guò)濾器之間不共享狀態(tài)，過(guò)濾器不知道上下游

47、的標(biāo)識(shí)符，輸出正確性不依賴于過(guò)濾器順序；適易于理解，支持重用，維護(hù)和增強(qiáng)容易，允許特定種類的專門分析，支持并發(fā)，交互不佳，需要額外空間，解析增加性能流失和過(guò)濾器編寫的復(fù)雜性，用于在有序數(shù)據(jù)上定義一系列獨(dú)立計(jì)算的應(yīng)用；特化形式Pipelines（線性拓?fù)洌┖虰atch Sequential（pipeline退化版）Implicit Invocation：組件發(fā)起一至多個(gè)事件，也可以注冊(cè)某個(gè)方法來(lái)響應(yīng)某個(gè)事件，當(dāng)時(shí)間發(fā)生時(shí)，連接件調(diào)用所有注冊(cè)該事件的方法，封裝共享數(shù)據(jù)，避免暴露存儲(chǔ)格式給計(jì)算模塊，數(shù)據(jù)更改時(shí)計(jì)算被隱式調(diào)用，典型應(yīng)用事件；組件是agent（對(duì)象，過(guò)程，進(jìn)程），連接件是廣播中介（事件處

48、理器），限制是事件發(fā)起者不知道事件影響那些組件，無(wú)法假設(shè)處理順序以及處理結(jié)果；復(fù)用支持極佳，系統(tǒng)演化容易，但難以保證正確性和完整性，且測(cè)試和診斷困難，適用于擁有松散耦合的組件集、每個(gè)都可能執(zhí)行一些使其他組件進(jìn)行處理的操作的應(yīng)用上面四種比較Main-program-and-subroutineObject-OrientedPipe and FilterImplicit InvocationChange in algorithmBadMediumGoodGoodChange in data representationBadGoodMediumMediumChang in functionsMed

49、iumMediumGoodMediumMake system interactiveMediumMediumBadMediumSpace performanceGoodGoodBadGoodTime performanceBadBadMediumGoodReuse componentsBadMediumGoodGoodRepository（Blackboard）：組件是一個(gè)表示系統(tǒng)正確狀態(tài)的中心數(shù)據(jù)結(jié)構(gòu)，一組操作中心數(shù)據(jù)結(jié)構(gòu)的獨(dú)立組件（agent），連接件是過(guò)程調(diào)用和直接內(nèi)存存取，限制是所有agent應(yīng)當(dāng)獨(dú)立并且依賴共享數(shù)據(jù)，檢查數(shù)據(jù)狀態(tài)并做出反應(yīng)（Pull vs. Push）；存儲(chǔ)大量數(shù)據(jù)的

50、方便方式，集中化管理，必須先對(duì)數(shù)據(jù)模型達(dá)成一致，中心數(shù)據(jù)體會(huì)成為瓶頸，數(shù)據(jù)演化昂貴，適用于中心問(wèn)題是建立擴(kuò)充和維護(hù)阻隔復(fù)雜中心信息體的應(yīng)用Repository vs. Blackboard：前者使用pull模型，易于實(shí)現(xiàn)但客戶端復(fù)雜并且需要輪詢數(shù)據(jù)；后者使用push模型，客戶端編程簡(jiǎn)化但需要復(fù)雜的結(jié)構(gòu)Layered：組件是一組過(guò)程或?qū)ο?，連接件是過(guò)程調(diào)用和限制可見(jiàn)性的方法調(diào)用，限制是系統(tǒng)組織成層次結(jié)構(gòu)，每層給上層提供服務(wù)并作為下層的client，躍層是不允許的；設(shè)計(jì)基于不同層次的抽象，更改一層最多再影響兩層，同層可互換提供服務(wù)增強(qiáng)復(fù)用，但不是所有系統(tǒng)都有明確的層次結(jié)構(gòu)，并且性能可能會(huì)需要躍層訪

51、問(wèn)以及實(shí)現(xiàn)部分訪問(wèn)，適用于擁有明確的服務(wù)種類從而可層次式組織的應(yīng)用，例如層次式通信協(xié)議和操作系統(tǒng)，特例是異常一般是無(wú)層次直接交互的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)view，連接件是過(guò)程調(diào)用、消息、事件、直接內(nèi)存存??；允許一個(gè)model上建立多個(gè)獨(dú)立view，view可同步，可“插拔”（易于修改）的view和co

52、ntroller，但增加了復(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ā)布者和訂閱者，連接件是事件Router復(fù)雜并且負(fù)責(zé)失敗；物理單元風(fēng)格Client-Server：分布式系統(tǒng)的特例；組件是client，連接件是RPC-based interact

53、ion 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，連接件是同步或異步消息傳遞但一般不共享內(nèi)存，交互的拓?fù)浣Y(jié)構(gòu)差異性和動(dòng)態(tài)性較大Distributed SystemDistributed Objects（middlewa

54、re）Distributed Resources（http）Distributed Services（web service）比較詳解1以模塊為對(duì)象的體系結(jié)構(gòu)風(fēng)格Main Program and Subroutine Style結(jié)構(gòu)：Components: 程序，功能，模塊Connectors: 函數(shù)間的調(diào)用特點(diǎn)：控制從頂層開(kāi)始，逐漸細(xì)化至最低層，不允許同級(jí)和向上調(diào)用層次化分解：先聲明后定義單線程控制隱含“子系統(tǒng)結(jié)構(gòu)“，分解結(jié)構(gòu)，子路徑屬于上個(gè)模塊的聚合但又無(wú)法調(diào)用回去層次化推理：只要子過(guò)程正確，即可保證整個(gè)鍋程正確，串行調(diào)度，正確性極好優(yōu)點(diǎn)：處理清晰，容易理解可強(qiáng)正確性控制，部分正確即可得整

55、體正確缺點(diǎn)：不利于修改復(fù)用；處理不好會(huì)變成公共耦合使用情景：順序系統(tǒng)，對(duì)系統(tǒng)正確性要求高的系統(tǒng)Object-Oriented Style結(jié)構(gòu)：Components: 對(duì)象或模塊Connectors: 函數(shù)或調(diào)用特點(diǎn)：所有數(shù)據(jù)信息封裝與隱藏每個(gè)對(duì)象都是自治的，互不干涉，彼此獨(dú)立對(duì)象有義務(wù)維護(hù)自己封裝信息的一致性和完整性所有component平等，可以任意調(diào)用，無(wú)層次限制優(yōu)點(diǎn)：因?yàn)閷?duì)象對(duì)其它對(duì)象隱藏它的表示，所以可以改變一個(gè)對(duì)象的表示，而不影響其它的對(duì)象。只要不改變接口，相互修改性較好。數(shù)據(jù)表示和相關(guān)操作封裝為抽象數(shù)據(jù)類型設(shè)計(jì)者可將一些數(shù)據(jù)存取操作的問(wèn)題分解成一些自治的交互代理程序的集合。 每部分

56、獨(dú)立，每部分正確性易于確定，方法在對(duì)象中被調(diào)用，可以將問(wèn)題分解為交互的代理缺點(diǎn)：為了使一個(gè)對(duì)象和另一個(gè)對(duì)象通過(guò)過(guò)程調(diào)用等進(jìn)行交互，必須知道對(duì)象的接口標(biāo)識(shí)，有依賴性。只要一個(gè)對(duì)象的標(biāo)識(shí)改變了，就必須修改所有其他明確調(diào)用它的對(duì)象。必須修改所有顯式調(diào)用它的其它對(duì)象，并消除由此帶來(lái)的一些副作用。例如，如果A使用了對(duì)象B，C也使用了對(duì)象B，那么，C對(duì)B的使用所造成的對(duì)A的影響可能是料想不到的。有重入問(wèn)題。使用情景：核心問(wèn)題是識(shí)別并保護(hù)相關(guān)信息體的程序Pipe and Filter Architectural Style結(jié)構(gòu)：Components: Filter,提供數(shù)據(jù)局部轉(zhuǎn)化，并且使用增量處理，已使得

57、輸出數(shù)據(jù)再所有輸入數(shù)據(jù)完成之前產(chǎn)生Connectors: Pipe，作為流傳輸?shù)耐ǖ?，把一個(gè)Filter的輸出傳到另一個(gè)的輸入特點(diǎn)：Filter之間不共享狀態(tài)和數(shù)據(jù)Filter不知道它上下游Filter，只知道自己的功能單個(gè)filter不需依賴要知道其他filter才能構(gòu)建的假設(shè)整個(gè)網(wǎng)絡(luò)的正確性不應(yīng)該依賴于Filter的排列順序完全獨(dú)立，可以隨時(shí)增減filter，可以并行開(kāi)發(fā)優(yōu)點(diǎn)：使得軟構(gòu)件具有良好的隱蔽性和高內(nèi)聚、低耦合的特點(diǎn)；易于理解，允許設(shè)計(jì)者將整個(gè)系統(tǒng)的輸入/輸出行為看成是多個(gè)過(guò)濾器的行為的簡(jiǎn)單合成；支持軟件重用。只要提供適合在兩個(gè)過(guò)濾器之間傳送的數(shù)據(jù)，任何兩個(gè)過(guò)濾器都可被連接起來(lái)；系

58、統(tǒng)維護(hù)和增強(qiáng)系統(tǒng)性能簡(jiǎn)單。對(duì)順序無(wú)依賴性，新的過(guò)濾器可以添加到現(xiàn)有系統(tǒng)中來(lái)；舊的可以被改進(jìn)的過(guò)濾器替換掉；允許對(duì)一些如吞吐量、死鎖等屬性的特殊分析；支持并行執(zhí)行。每個(gè)過(guò)濾器是作為一個(gè)單獨(dú)的任務(wù)完成，因此可與其它任務(wù)并行執(zhí)行。缺點(diǎn)：通常導(dǎo)致進(jìn)程成為批處理的結(jié)構(gòu)。這是因?yàn)殡m然過(guò)濾器可增量式地處理數(shù)據(jù)，但它們是獨(dú)立的，所以設(shè)計(jì)者必須將每個(gè)過(guò)濾器看成一個(gè)完整的從輸入到輸出的轉(zhuǎn)換。傳輸數(shù)據(jù)需要額外的空間。不適合處理交互的應(yīng)用。當(dāng)需要增量地顯示改變時(shí)，這個(gè)問(wèn)題尤為嚴(yán)重。各部分獨(dú)立，難以全局控制。因?yàn)樵跀?shù)據(jù)傳輸處理的不一致性，每個(gè)過(guò)濾器都增加了打包，封裝和分解數(shù)據(jù)的工作，這樣就導(dǎo)致了系統(tǒng)性能下降，并增加了編

59、寫過(guò)濾器的復(fù)雜性。使用情景：對(duì)有序數(shù)據(jù)進(jìn)行一系列獨(dú)立運(yùn)算處理的程序，如Shell，Compiler特殊：流水線和批處理Implicit invocation (Event based ) Style結(jié)構(gòu)：Components: agent代理程序(對(duì)象、程序、進(jìn)程)Connectors: broadcast mediums廣播媒介(事件處理器)特點(diǎn)：一個(gè)組件可聲明事件，另一些組件以函數(shù)去注冊(cè)事件，當(dāng)事件觸發(fā)時(shí)，廣播媒介根據(jù)注冊(cè)分發(fā)事件，Connector自動(dòng)觸發(fā)注冊(cè)的函數(shù)調(diào)用。一個(gè)或者多個(gè)事件拋出者不知道誰(shuí)接受事件，不需假設(shè)一定有處理和誰(shuí)處理不能假定事件是否被處理以及被處理的順序優(yōu)點(diǎn)：為軟件重

60、用提供了強(qiáng)大的支持。當(dāng)需要將一個(gè)構(gòu)件加入現(xiàn)存系統(tǒng)中時(shí)，只需將它注冊(cè)到系統(tǒng)的事件中。為改進(jìn)系統(tǒng)帶來(lái)了方便。當(dāng)用一個(gè)構(gòu)件代替另一個(gè)構(gòu)件時(shí)，不會(huì)影響到其它構(gòu)件的接口。缺點(diǎn)：正確性和完整性無(wú)法保證難以測(cè)試和調(diào)試構(gòu)件放棄了對(duì)系統(tǒng)計(jì)算的控制。一個(gè)構(gòu)件觸發(fā)一個(gè)事件時(shí)，不能確定其它構(gòu)件是否會(huì)響應(yīng)它。而且即使它知道事件注冊(cè)了哪些構(gòu)件的構(gòu)成，它也不能保證這些過(guò)程被調(diào)用的順序。數(shù)據(jù)交換的問(wèn)題。有時(shí)數(shù)據(jù)可被一個(gè)事件傳遞，但另一些情況下，基于事件的系統(tǒng)必須依靠一個(gè)共享的倉(cāng)庫(kù)進(jìn)行交互。在這些情況下，全局性能和資源管理便成了問(wèn)題。既然過(guò)程的語(yǔ)義必須依賴于被觸發(fā)事件的上下文約束，關(guān)于正確性的推理存在問(wèn)題。使用情景：一系列松耦