【文章內(nèi)容簡(jiǎn)介】 e MovieFinder finder。 public MovieLister() { finder = new ColonDelimitedMovieFinder()。 } ? 對(duì)抗變化： – 文件清單的名字更改： ? 可以從一個(gè)配置文件獲得文件名。 – 如果用 SQL 數(shù)據(jù)庫(kù)、 XML 文件、 web service，或者另一種格式的文本文件來(lái)存儲(chǔ)影片清單： ? 用另一個(gè)具體的類來(lái)獲取數(shù)據(jù)。該類從 MovieFinder接口派生即可。 – 創(chuàng)建合適的 MovieFinder派生類的實(shí)例： ? 不能對(duì)抗此變化。 102 配置文件 ? 設(shè)定配置文件： XML 文件是比較理想的配置方式。 beans bean id=MovieLister class= property name=finder ref local=MovieFinder/ /property /bean bean id=MovieFinder class= property name=filename value/value /property /bean /beans 103 第三單元：用 UML輔助系統(tǒng)分析與設(shè)計(jì) 104 UML簡(jiǎn)介及常見(jiàn)疑難問(wèn)題辨析 105 UML用來(lái)描述模型的內(nèi)容有 3種 ,分別是事物 ( Things )、關(guān)系Relationships )和圖 ( Diagrams )。 106 UML中的關(guān)系 ? UML中的關(guān)系 (Relationships )主要包括 4種 : ? 關(guān)聯(lián)關(guān)系 ? 依賴 ( Dependency)關(guān)系 ? 泛化 ( Generalization )關(guān)系 ? 實(shí)現(xiàn) ( Realization )關(guān)系 107 一些常見(jiàn)問(wèn)題辨析 ? 類的層次結(jié)構(gòu)表示 ? 屬性與聚合 ? 關(guān)聯(lián)角色 ? 關(guān)聯(lián)類 108 層次結(jié)構(gòu) P a r t A s s e m b l yI C o m p o n e n t*109 領(lǐng)域建模－重?cái)?shù) 110 細(xì)化類模型 111 關(guān)聯(lián)角色 ? 關(guān)聯(lián)角色名出現(xiàn)在關(guān)聯(lián)終端的旁邊。當(dāng)僅僅使用關(guān)聯(lián)名不足夠表達(dá)清楚后，可以用關(guān)聯(lián)角色名來(lái)加強(qiáng)表達(dá)。 ? 可以把每個(gè)名稱都當(dāng)成偽屬性，關(guān)聯(lián)角色名提供了一種可以遍歷關(guān)聯(lián)的方法。 P e r s o n C o m p a n y0 . . 1*+ e m p l o y e e + e m p l o y e re m p l o y e eJ o e D o eM a r y B r o w nJ e a n S m i t he m p l o y e rS i m p le xS i m p le xU n it e d W id g e t s112 ? 在創(chuàng)建類圖時(shí)，應(yīng)該為使用正確的角色名，而不是為每個(gè)引用引入一個(gè)獨(dú)立的類。 ? 因?yàn)榻巧梢詤^(qū)分對(duì)象，所以附在一個(gè)類上的關(guān)聯(lián)名必須唯一（可以把角色名想象成類的偽屬性）。同樣，角色名不應(yīng)該與類的屬性名重復(fù)。 P a r e n t C h il d0 . . n2P e r s o n*0 . . 2+ C h i l d+ P a r e n t113 關(guān)聯(lián)類 ? 正如可以用屬性描述類的對(duì)象一樣，也可以用屬性來(lái)描述關(guān)聯(lián)的鏈接，可以把這樣的一組屬性組成關(guān)聯(lián)類。 114 Actor的一些注意事項(xiàng) ? 包括人與系統(tǒng)，總是外部的。 ? 定義了邊界。 ? Actor是“角色”，不是特定的人或特定的事。 ? 要有恰當(dāng)?shù)拿帧? ? 可以泛化 ? 不是可有可無(wú)的東西。另一方面它可以劃分系統(tǒng)與外部實(shí)體的界限，是系統(tǒng)設(shè)計(jì)的起點(diǎn)。 115 用例的一些注意事項(xiàng) ? 是需求分析的第一步。用戶首先關(guān)心功能。 ? 用例是對(duì)一個(gè)系統(tǒng)或一個(gè)應(yīng)用的一種單一的使用方式所作的描述 ,是關(guān)于單個(gè)活動(dòng)者在與系統(tǒng)對(duì)話中所執(zhí)行的處理行為的陳述序列。 ? 不是事件流。 ? 不是需求規(guī)格說(shuō)明，但反映了主要的功能性需求。 ? 識(shí)別用例最好是從分析流開(kāi)始。 ? 每個(gè)用例都是獨(dú)立的。 ? 用例名用動(dòng)賓結(jié)構(gòu)描述，不要寫(xiě)成一個(gè)名詞。 ? 用例是分層的，一般而言，高層 /中層用例更有實(shí)際意義。 ? 不要將不同的用例混合在一起。 ? 用例與編碼：低層的用例可以輔助編碼，高層的不能。 ? 擴(kuò)展用例：基礎(chǔ)用例不必知道擴(kuò)展用例的細(xì)節(jié)，只提供擴(kuò)展點(diǎn)。 116 倉(cāng)庫(kù)信息系統(tǒng)的用例圖 117 借鑒 RUP的 UML建模與分析 118 全局分析 ? 全局分析側(cè)重于定義擬建系統(tǒng)所采用的構(gòu)架以及影響構(gòu)架的要素。全局分析充分利用相似或問(wèn)題中的經(jīng)驗(yàn)，避免在確定構(gòu)架上浪費(fèi)人力和物力。 ? 選用架構(gòu)模式 ? 識(shí)別關(guān)鍵抽象：尋找那些無(wú)論在問(wèn)題域或方案領(lǐng)域都具有普遍意義的概念點(diǎn)。 ? 標(biāo)識(shí)分析機(jī)制：將那些問(wèn)題領(lǐng)域（應(yīng)用邏輯）沒(méi)有直接關(guān)聯(lián)的計(jì)算機(jī)概念及相應(yīng)的復(fù)雜行為表述為支撐分析工作的“占位符”。 ? 選定分析局部：針對(duì)擬建系統(tǒng)的整體架構(gòu)，找出那些蘊(yùn)含相對(duì)高風(fēng)險(xiǎn)的局部作為工作內(nèi)容。 119 全局分析 ? 常見(jiàn)的分析機(jī)制 留存 分布式處理 安全性 進(jìn)程間通信 消息路由 進(jìn)程控制與同步 交易事務(wù)管理 信息交換 信息的冗余 錯(cuò)誤檢測(cè)、處理和報(bào)告 數(shù)據(jù)格式轉(zhuǎn)換 120 局部分析 ? 提取分析類 ? 轉(zhuǎn)述需求場(chǎng)景 ? 整理分析類 121 局部分析 ? 分析類的類型劃分 眾多實(shí)踐表明，如果立足于軟件功能需求，擬建系統(tǒng)往往在三個(gè)維度易于發(fā)生變化：一、擬建系統(tǒng)和外部要素之間交互的邊界；第二，擬建系統(tǒng)要記錄和維護(hù)的信息；第三，擬建系統(tǒng)在運(yùn)行中的控制邏輯。通常按照這三個(gè)變化因素的維度，將分析類劃分為三種類型：邊界類、控制類、實(shí)體類 系統(tǒng)邊界 Use Case 行為協(xié)調(diào) 基本信息 122 局部分析 123 局部分析 124 局部分析 125 局部分析 ? 整理分析類 分析類是這樣的類：它代表問(wèn)題域中的簡(jiǎn)潔抽象； ? 分析類映射到真實(shí)世界的業(yè)務(wù)概念（并且據(jù)此仔細(xì)命名）。 問(wèn)題域是首先產(chǎn)生軟件系統(tǒng)（以及從此而來(lái)的軟件開(kāi)發(fā)活動(dòng)）需求的域。通常，這是特定的業(yè)務(wù)領(lǐng)域，如在線銷(xiāo)售或者客戶關(guān)系管理。然而，務(wù)必注意，問(wèn)題域可能根本不是任何特定業(yè)務(wù)活動(dòng)，但 是可能產(chǎn)生需要軟件在其上運(yùn)轉(zhuǎn)的一塊物理硬件 ─這是嵌入式系統(tǒng)?；旧希袠I(yè)務(wù)軟件開(kāi)發(fā)服 務(wù)于某種業(yè)務(wù)需求，自動(dòng)化一個(gè)已有業(yè)務(wù)過(guò)程或者開(kāi)發(fā)具有有意義的軟件組件的新產(chǎn)品。 126 分析類的職責(zé) ? 職責(zé)是類和它的客戶之間的契約或者是類對(duì)它的客戶的義務(wù)。本質(zhì)上，職責(zé)是類提供給其他類的 服務(wù)。分析類具有直接同類（由它的名稱所表達(dá)）的目的相一致的以及直接同該類正在建模的真實(shí)世 界“事物”相一致的非常內(nèi)聚的職責(zé)集合，這一點(diǎn)是至關(guān)重要的。例如ShoppingBasket示例，你將期 望該類具有如下職責(zé)： ? 向購(gòu)物籃添加商品； ? 從購(gòu)物籃刪除商品； ? 顯示購(gòu)物籃中的商品。 這是內(nèi)聚的職責(zé)集合，一切都是為了維護(hù)客戶選擇的商品集合。它是內(nèi)聚的，因?yàn)樗械穆氊?zé)都朝著相同的目標(biāo) ─維護(hù)客戶已經(jīng)選擇的商品集合。實(shí)際上，我們能夠把這些職責(zé)概括為非常高級(jí)層 次的職責(zé)“維護(hù)購(gòu)物籃”。 ? 同樣，向 ShoppingBasket 中添加如下職責(zé)： 127 分析類的職責(zé) ? 驗(yàn)證信用卡； ? 接收付款； ? 打印收據(jù)。 但這些職責(zé)似乎同購(gòu)物籃的目的或直覺(jué)語(yǔ)法不匹配。它們不是內(nèi)聚的，顯然應(yīng)該賦予其他什么類 ─ 可能是類CreditCardCompany、類 Checkout以及類 ReceiptPrinter。把職責(zé)適當(dāng)?shù)胤峙浣o分析類 以最大化每個(gè)類中的內(nèi)聚性，是很重要的。 ? 最后，良好的類與其他類之間具有最低數(shù)目的耦合。我們以給定類與其他類具有關(guān)系的數(shù)目來(lái)度量類間的耦合度。類間職責(zé)的平均分布趨向于產(chǎn)生低耦合度。把控制或職責(zé)局限于單一的類趨向于增 加到該類的耦合度。 128 分析類經(jīng)驗(yàn)法則 ? 以下是創(chuàng)建形式良好的分析類的一些經(jīng)驗(yàn)法則。 ? 每個(gè)類大約 3~5個(gè)職責(zé) ─典型地，類應(yīng)該保持盡可能簡(jiǎn)單，這通常限制類能夠支持的 3~5個(gè)職 責(zé)的數(shù)目。先前 ShoppingBasket 的示例是帶有小的和可管理數(shù)目職責(zé)的專注的類的好的示例。 ? 不存在獨(dú)立的類 ─好的 OO分析和設(shè)計(jì)的精華是，類相互協(xié)作讓用戶受益。同樣，每個(gè)類應(yīng)該 同小部分類協(xié)作以提供所期望的功能。類可以把它們的一些職責(zé)托付給專注于特定功能的其他“輔助”類。 ? 當(dāng)心很多非常小的類 ─ 有時(shí)很難取得正確的平衡。如果模型看起來(lái)具有大量的非常小的類， 每個(gè)類都具有一個(gè)或者兩個(gè)職責(zé)，那么你應(yīng)該仔細(xì)查看以把一些小的類整合成更大的類。 129 ? 當(dāng)心少數(shù)幾個(gè)非常龐大的類 ─上述的反面是，模型具有很少的類，但每個(gè)類都是具有職責(zé)數(shù) 量（ 5）的龐大的類。解決問(wèn)題的策略是依次查看這些類，看看是否每個(gè)類都能夠被分解成為 兩個(gè)或者多個(gè)能夠承擔(dān)恰當(dāng)數(shù)目職責(zé)的、更小的類。 ? 當(dāng)心“偽類” ─偽類其實(shí)是一般的過(guò)程函數(shù)，它偽裝成類。 ? 當(dāng)心萬(wàn)能類 ─ 存在似乎能夠承擔(dān)任何工作的類?？纯疵Q為“ system‖和“ controller‖的 類！處理這個(gè)問(wèn)題的策略是看看萬(wàn)能類的職責(zé)是否能夠分解成內(nèi)聚的子集。如果是，每個(gè)這些 內(nèi)聚職責(zé)集合可能獨(dú)立成類。這些更小的類協(xié)作以實(shí)現(xiàn)由原始萬(wàn)能類所提供的行為。 130 分析類經(jīng)驗(yàn)法則 – 避免深度繼承樹(shù) ─設(shè)計(jì)良好的繼承層次的本質(zhì)是繼承層次中每個(gè)抽象層次應(yīng)該具有良好定義 的目的。容易添加很多實(shí)際上不能服務(wù)于任何目的層次。 – 實(shí)際上，通常的錯(cuò)誤是使用繼承來(lái)實(shí) 現(xiàn)一種功能分解，其中每個(gè)抽象層次恰有一個(gè)職責(zé)！ 無(wú)論從哪個(gè)方面來(lái)講，這都是無(wú)意義的，是會(huì)導(dǎo)致復(fù)雜的、難以理解的模型。 – 在分析中，類代表業(yè)務(wù)事物，而業(yè)務(wù)事物趨向于形成更寬（不超過(guò)三層）的繼承層次。 我們把三層或者更多層次的繼承認(rèn)為是“深度”繼承。 131 第四單元：設(shè)計(jì)模式與軟件設(shè)計(jì)思想 132 設(shè)計(jì)模式 133 設(shè)計(jì)模式在實(shí)際開(kāi)發(fā)中的運(yùn)用 ? 復(fù)用現(xiàn)有的、高質(zhì)量的、針對(duì)常見(jiàn)的重復(fù)出現(xiàn)問(wèn)題的解決方案。 ? 建立通用的術(shù)語(yǔ)以改善團(tuán)隊(duì)內(nèi)部的溝通。 ? 將思考轉(zhuǎn)移到更高的視角。 ? 判斷是否擁有正確的設(shè)計(jì)，而不僅僅使一個(gè)可以運(yùn)行的設(shè)計(jì)。 ? 改善代碼的可修改性。 ? 發(fā)現(xiàn)“龐大的繼承體系”的替代方案。 134 GoF中的模式分類 135 設(shè)計(jì)模式的特點(diǎn) ? 設(shè)計(jì)模式最根本的意圖是適應(yīng)需求變化 – 隔離變化的部分與不變的部分，將之封裝起來(lái)。 ? 針對(duì)接口編程，而不要針對(duì)實(shí)現(xiàn)編程 ? 達(dá)成高內(nèi)聚合低耦合，提高復(fù)用 ? 提倡優(yōu)先使用聚合，而不是繼承 136 例 ? 一個(gè)日志記錄工具。目前需要提供一個(gè)日志 API，提供客戶方便地調(diào)用。 ? 該日志要求被記錄到指定的文本文件中，記錄的內(nèi)容屬于字符串類型，其值由客戶提供。 ? 可以容易地定義一個(gè)日志對(duì)象。 public class Log { public void Write(string target, string log) { //實(shí)現(xiàn)內(nèi)容 。 } } 當(dāng)客戶需要調(diào)用日志的功能時(shí)，可以創(chuàng)建日志對(duì)象，完成日志的記錄： Log log = new Log()。 (―‖, ―log‖)。 137 Log+ W r it e ( )I L o g I n t e r f a c e + E x e c u t e ( )L o g 2 T x t F il e+ E x e c u t e ( )L o g 2 X m lF i le+ E x e c u t e ( )L o g 2 D B+ E x e c u t e ( )138 139 例 ? 我們需要設(shè)計(jì)一個(gè)數(shù)據(jù)庫(kù)組件，它能夠訪問(wèn) Sql Server數(shù)據(jù)庫(kù)。如果用 ，需要使用如下的對(duì)象： – SqlConnection, SqlCommand, SqlDataAdapter等。 ? 不用模式的做法：可以直接創(chuàng)建這些對(duì)象： – SqlConnection connection = new SqlConnection(strConnection)。 – SqlCommand mand = new SqlCommand(connection)。 – SqlDataAdapter adapter = new SqlDataAdapter(