細化迭代基礎章第1頁/共146頁主要內容第17章GRASP基于職責設計對象第18章使用GRASP的對象設計示例第2頁/共146頁第17章GRASP：基于職責設計對象第3頁/共146頁

引言我們已經創(chuàng)建了領域模型確定有什么樣的方法，屬于誰，對象之間如何交互，這是開發(fā)面向對象系統(tǒng)的核心但是如何做?GRASP模式是幫助我們理解詳細的原則和所需要的思考方法的學習工具這些模式與如何將責任分配給相關類GRASP：GeneralResponsibilityAssignmentSoftwarePatternGRASP的核心是自己干自己能干的事，自己只干自己的事第4頁/共146頁17.1UML與設計原則最關鍵的軟件開發(fā)工具是受過良好設計原則訓練的思維，而不是UML或任何其他技術第5頁/共146頁17.2對象設計：輸入、活動和輸出的示例輸入第6頁/共146頁對象設計中的活動對具有創(chuàng)造性、最苦難的部分建模。運用各種OO設計原則給協(xié)作中的對象分配職責對象設計的輸出：針對設計中的難點創(chuàng)建UML交互圖、類圖和包圖UI的草圖和原型數(shù)據(jù)庫模型報表的草圖和原型第7頁/共146頁17.3職責和職責驅動設計職責：類元的契約或義務對象的行為職責:自身執(zhí)行一些行為，例如創(chuàng)建對象或計算初始化其他對象中的動作控制或者協(xié)調其它對象的活動如：Sale負責創(chuàng)建SalesLineItem對象的認知職責對私有封裝數(shù)據(jù)的認知對相關對象的認知對其能夠導出或計算的事物的認知如：Sale負責認知其總額第8頁/共146頁職責&方法職責不等同于方法，職責是一種抽象，而方法實現(xiàn)了職責，該方法可以單獨動作，也可以與其他方法和對象協(xié)作。例如：Sale

類可以定義一個或多個方法來計算總價命名為getTotal的方法為了完成此職責，Sale可能與其它對象協(xié)作，例如發(fā)送getSubTotal

消息給每一個SalesLineItem

對象，來獲取每一個類別的價格第9頁/共146頁17.5職責、GRASP和UML圖之間的聯(lián)系職責可以通過編程實現(xiàn)或者可以通過創(chuàng)建交互圖來進行分配建議采用GRASP的基本原則職責與方法是相關的第10頁/共146頁17.6什么是模式在我們人類社會中，許多方面的成功經驗都可以歸結為模式事實上，教育的重要目標就是把學習的模式從一代傳向下一代在OO設計中，模式是對問題和解決方案的已命名描述優(yōu)秀的模式的意圖是將已有的經過驗證的知識、慣用法和原則匯編起來——“新模式”矛盾修飾語。模式是一種學習工具，可以用來命名、表示和記憶那些基本和經典的設計思想第11頁/共146頁成為一個軟件設計大師首先學習規(guī)則例如，算法，數(shù)據(jù)結構和軟件語言然后學習原則例如，結構化編碼，模塊化編碼，面向對象編碼，遺傳編碼等等但是，為了真正掌握軟件設計，還必須學習其它大師的設計這些設計包含了必須理解，記憶和重復運用的模式這種模式也是非常多的第12頁/共146頁模式優(yōu)點模式對專家的知識和設計中的優(yōu)缺點進行了顯示獲取，并盡力使這種專家知識被廣泛應用模式可以改進開發(fā)者之間的溝通模式名字構成一個詞匯集模式有助于面向對象技術的推廣第13頁/共146頁注意點不要把所有的東西都作為一個模式開發(fā)戰(zhàn)略性的領域模式，并重用現(xiàn)存的戰(zhàn)術型模式模式作者，應用開發(fā)者和領域專家之間的密切合作在文檔中清楚表明何時可以應用，何時不可以應用第14頁/共146頁GOF關于設計模式的著作KentBeck首先提出軟件命名模式的思想1994年模式的“圣經”《DesignPatterns》極為暢銷Gamma、Helm、Johnson和VlissidesGRASP定義了9個基本OO設計原則和基本設計構件。某人的模式是其他人的原始構造塊。第15頁/共146頁17.8使用GRASP進行對象設計的簡短示例本案例用到了9個GRASP模式中的以下幾個：創(chuàng)建者(Creator)信息專家(InformationExpert)低耦合(LowCoupling)控制器(Controller)高內聚(HighCohesion)第16頁/共146頁創(chuàng)建者(Creator)問題：誰創(chuàng)建Square對象？名稱：創(chuàng)建者(Creator)問題：誰創(chuàng)建了A？解決方案（可被視作建議）：如果以下條件之一為真時（越多越好），將創(chuàng)建類A示例的職責分配給類B：B“包含”或組成聚集了A.B記錄A.B緊密地使用A.B具有A的初始化數(shù)據(jù).LRG：不用AB324或ZC17命名的理由第17頁/共146頁從領域模型中獲取靈感，使Board軟件對象包含Square軟件對象。第18頁/共146頁運用創(chuàng)建者模式需要循環(huán)創(chuàng)建40個方格第19頁/共146頁信息專家(InformationExpert)問題：如果給定鍵值，誰知道Square對象的相關信息？s=getSquare（name）名稱：信息專家(InformationExpert)問題：給對象分配職責的基本原則是什么？解決方案（建議）：把職責分配給具有完成該職責所需信息的那個類。第20頁/共146頁為了能夠檢索和表示任何Square，s=getSquare（name）

，某個對象必須知道所有Square信息（持有其信息）Board聚集所有Square對象，因此Board具有履行此職責所必需的信息，所以將獲知特定Square的職責分配給Board對象第21頁/共146頁低耦合(LowCoupling)問題：為什么是Board而不是Dog（某個任意類）？耦合:就是對某元素與其它元素之間的連接、感知和依賴的量。元素:既可以是功能、對象也可以指系統(tǒng)、子系統(tǒng)、模塊。A與B耦合：假如一個元素A去連接元素B，或者通過自己的方法可以感知B，或者當B不存在的時候就不能正常工作，那么就說元素A與元素B耦合。名稱：低耦合(LowCoupling)問題：如何減少因變化產生的影響？解決方案（建議）：分配職責以使（不必要的）耦合保持在較低的水平。用該原則對可選方案進行評估。第22頁/共146頁為什么是Board而不是Dog?Dog和Board都需要知道Square，耦合高！第23頁/共146頁信息專家模式支持低耦合回到信息專家的動機：該原則可以知道我們作出支持低耦合的選擇專家讓我們尋找這樣的對象，該對象具有職責所需的大部分信息，并把職責分配給該對象。如果分配給Dog，則存在更多的信息或對象必須被某些事物所分享，而這些事物遠離信息源或對象的本源。第24頁/共146頁控制器MVS原則：UI對象不應當包含應用邏輯或業(yè)務邏輯，如：計算游戲者的移動！應該把請求委派給領域層的領域對象！第25頁/共146頁問題：怎樣將UI層連接到應用邏輯層？從UI層接收playGame消息的第一個對象是Board嗎？或者其他對象？控制器(Controller)模式定義名稱：控制器(Controller)問題：在UI層之上首先接收和協(xié)調（“控制”）系統(tǒng)操作的對象是什么？解決方案（建議）：把職責分配給能代表下列選擇之一的對象：代表全部“系統(tǒng)”、“根對象”、運行軟件的設備或主要的子系統(tǒng)代表發(fā)生系統(tǒng)操作的用例場景如：MonopolyGame，System如：PlayMonoployGameHandler如：電話機或銀行兌鈔機第26頁/共146頁應用控制器模式——使用MonopolyGame第27頁/共146頁高內聚(HighCohesion)MonopolyGame對象自己完成全部工作為playGame請求對工作進行了委派和協(xié)調第28頁/共146頁名稱：高內聚(HighCohesion)問題：怎樣使對象保持有內聚、可理解和可管理，同時具有支持低耦合的附加作用？解決方案（建議）：職責分配應該保持高內聚，以此來評估備選方案。右側的設計方案比左側的方案更好地支持了高內聚。高內聚(HighCohesion)模式定義第29頁/共146頁17.9在對象設計中應用GRASPGRASP（GeneralResponsibilityAssignmentSoftwarePatterns）通用職責分配軟件模式9個模式如下:創(chuàng)建者（Creator）信息專家（InformationExpert）低耦合（LowCoupling）控制器（Controller）高內聚（HighCohesion）多態(tài)性(Polymorphism）純虛構(PureFabrication)間接性(Indirection)防止變異(ProtectedVariations)本章先介紹前五個，后面的四個將于25章介紹第30頁/共146頁17.10創(chuàng)建者（Creator）問題誰來負責創(chuàng)建某些類的新實例?在面向對象系統(tǒng)中對象的創(chuàng)建是一個最普通的活動，如果分配的好，設計就能夠支持低耦合，提高清晰度、封裝性和可復用性。我們需要一個分配創(chuàng)建責任的通用原則第31頁/共146頁解決方案將創(chuàng)建類A的實例的責任分配給類B，如果一個或多個下面的條件為真（越多越好）:B聚合了（aggregates）A對象B包含了（contains）A對象B記錄了（records）A對象的實例B密切使用（closelyuses）A對象B擁有傳遞給創(chuàng)建A所需要的初始化數(shù)據(jù)(因此B是創(chuàng)建A的專家)B是對象A的創(chuàng)建者第32頁/共146頁示例在POS應用，誰需要負責創(chuàng)建SalesLineItem（條目）實例呢?部分領域模型第33頁/共146頁sale包含了（聚集）許多SalesLineItem

對象，所以是良好候選者。第34頁/共146頁討論組合對象是創(chuàng)建其組成部分的良好候選者。有時創(chuàng)建者可以通過尋找初始化數(shù)據(jù)的類來確定創(chuàng)建者，這些數(shù)據(jù)將在創(chuàng)建過程中傳遞給被創(chuàng)建者。

例如，假設Payment

的一個實例需要被初始化，在創(chuàng)建時，需要攜帶Sale

總額信息。由于Sale

知道總價，Sale

是Payment的侯選創(chuàng)建者。第35頁/共146頁禁忌許多時候，創(chuàng)建過程有很強的復雜性，例如由于性能原因需要回收實例，依據(jù)外部屬性值有條件的創(chuàng)建一組相近似的類的一個實例，如：XXXFactory.newInstance()來創(chuàng)建實例。建議采用Factory類（抽象、具體工廠類）參見26.4節(jié)第36頁/共146頁優(yōu)點低耦合，意味者較低的維護依賴性和較高的復用性，已經有對被創(chuàng)建類的可見性相關模式或原則：低耦合具體工廠和抽象工廠整體-部分第37頁/共146頁17.11信息專家（專家）問題：給對象分配職責的基本原則是什么？設計模型可能定義成百上千個軟件對象，一個應用中也可能需要將成百上千項責任進行分配目的：易于理解，維護，擴展和重用解決方案將責任分配給信息專家，它具有實現(xiàn)這個職責所必需的信息。第38頁/共146頁示例NextGENPOS應用，某個類需要知道銷售總額誰負責了解銷售總額?信息專家建議：具有確定總額所需信息的那個對象類現(xiàn)在需要回答的問題：哪里找所需信息的類？如果已經有設計模型，并且包含了相關的類，首先關注它們。否則，查看領域模型第39頁/共146頁部分領域模型第40頁/共146頁確定總額需要哪些信息？銷售的所有SalesLineItem實例及其小計之和第41頁/共146頁SalesLineItem.quantity信息專家：SalesLineItemProcuctionDescription.price信息專家：ProcuctionDescription確定商品的小計需要知道哪些信息？第42頁/共146頁三個對象的設計類分配了如下職責：

設計類職責Sale知道銷售的總額SalesLineItem知道商品的小計ProductSpecification知道產品的價格第43頁/共146頁討論當信息分布在不同的對象中，他們需要相互間通過消息進行交互以分擔工作在真實的世界中，對象可能沒有生命的，但是在軟件中，對象是“活著的”或者“有生命的”，并且它們可以承擔責任，完成任務。例如：在企業(yè)中，誰應該作盈利或虧損的結論？答案：首席財務官！但是首席財務官必需需要會計師的借貸報告！第44頁/共146頁禁忌沒有萬能藥專家模式可能在某些情況中造成耦合和內聚例如，誰負責將Sale保存在數(shù)據(jù)庫？專家建議將此職責分配給Sale。但是，如果這樣的話，會導致：內聚、耦合及冗余方面的問題。違反基本的架構原則：即設計要分離主要的系統(tǒng)關注。我們應該將應用邏輯放在一個地方，將數(shù)據(jù)庫邏輯放在另外一個地方(持久化服務子系統(tǒng))第45頁/共146頁優(yōu)點實現(xiàn)了信息封裝，因為對象使用它們自己的信息完成任務：低耦合行為分布在擁有所需要的信息的類上相關模式：低耦合高內聚第46頁/共146頁17.12低耦合問題：怎樣降低依賴性，減少變化帶來的影響，提高重用性。耦合是對一個元素與其他元素的連接，擁有知識，依賴等關系的強烈程度的度量。高耦合造成：相關的類的變化造成本體被迫變化難以單獨的理解難以重用，牽涉到它所依賴的類。解決方案分配職責，使得耦合性盡可能的低第47頁/共146頁示例我們需要創(chuàng)建一個Payment

實例并將其與Sale關聯(lián)。第48頁/共146頁方案1(創(chuàng)建者模式）Register記錄了Payment，所以Register為創(chuàng)建Payment的候選者。耦合：

Register與PaymentRegister與SalePayment與Sale第49頁/共146頁方案2：由Sale來創(chuàng)建Payment對象耦合：Register與Sale Sale與Payment√第50頁/共146頁討論低耦合是一個在設計中時時需要記住的原則；它也是需要一直考慮的目標。這是設計者用來評估設計決策時運用的一個評價準則。不能脫離專家和高內聚等其他模式孤立地考慮。子類和超類有很強的耦合性。沒有絕對的度量標準來衡量耦合程度的高低。低耦合的極端例子：類之間沒有耦合。對象之間要有適度的耦合。第51頁/共146頁禁忌對穩(wěn)定的元素和普遍的元素的高耦合一般不是一個問題例如，一個JavaJ2EE應用對Java庫(java.util,等等）的耦合沒有問題,因為它們是穩(wěn)定的，并被普遍使用第52頁/共146頁權衡利弊高耦合本身不是問題所在，要避免和不穩(wěn)定元素之間的高耦合，如接口，實現(xiàn)等。例子：NextGen項目中，系統(tǒng)要連接不同的第三方稅金計算器，應該為這種實際的變化點進行低耦合設計。優(yōu)點：其他組件中的變更不會造成影響由于分離，便于理解方便重用相關模式防止變異第53頁/共146頁17.13：控制器（Controller）問題：在UI層之上首先接收和協(xié)調系統(tǒng)操作的第一個對象是什么？誰應該為處理輸入系統(tǒng)事件負責?一個控制器是一個沒有用戶界面的對象，負責接收和處理系統(tǒng)事件?？刂破鞫x了系統(tǒng)操作的方法解決方案將接收和處理系統(tǒng)事件消息的責任分配給代表下列方面的類:代表整個系統(tǒng)，設備或子系統(tǒng)代表用例場景，在該場景中發(fā)生系統(tǒng)事件，通常命名為<UseCaseName>Handler、<UseCaseName>Coordinator或<UseCaseName>Session（用例或會話控制器）第54頁/共146頁示例在NextGen應用中，有下列幾個系統(tǒng)操作第55頁/共146頁第56頁/共146頁代表整個系統(tǒng)，設備或子系統(tǒng)Register，POSSystem代表一個與系統(tǒng)事件相對應的用例場景ProcessSaleHandler,ProcessSaleSession根據(jù)控制器模式，給出兩個選擇第57頁/共146頁討論可以使用同一個控制類來處理一個用例中的所有系統(tǒng)事件以維護控制器中有關用例狀態(tài)的信息一般，控制器將需要完成的工作分配給其他對象；它負責協(xié)調或者控制活動，自己不做太多工作。第58頁/共146頁外觀控制器它代表了整個系統(tǒng)，設備或一個子系統(tǒng)它提供了從UI層往其他層的服務調用的主要入口對整個物理單元的抽象，例如Register,TelecommSwitch,Phone

或Robot代表了整個軟件系統(tǒng)的類，例如POSSystem設計者選擇用來表示整個系統(tǒng)，子系統(tǒng)的其他概念，例如如果是一個游戲軟件，選擇ChessGame什么時候我們選擇外觀控制器?當沒有“過多”的系統(tǒng)事件，或者UI不能把系統(tǒng)事件消息重定向到其他控制器（如在消息處理系統(tǒng)中）時，選擇外觀控制器是合適的。第59頁/共146頁用例控制器對每一個用例設置一個單獨的控制器這是支持系統(tǒng)的人工造物例如，在NextGen應用中，例如ProcessSale等用例可以與ProcessSaleHandler類關聯(lián)什么時候我們選擇用例控制器?當有太多的系統(tǒng)事件并設計不同的過程，用例控制器是一個好的選擇。它將處理它們的任務分配給那些可管理的單獨的類，也提供了一個獲知和推理目前進行中的場景的當前狀態(tài)的基礎。第60頁/共146頁第61頁/共146頁在統(tǒng)一過程中：邊界對象（BoundaryObjects）是接口的抽象實體對象（EntityObjects）是獨立于應用（經常是持久性）領域軟件對象控制對象（ControlObjects）是控制器模式中描述的用例處理器第62頁/共146頁優(yōu)點提高了重用的可能性，提供了可插拔的接口-它保證了接口層不處理應用邏輯對用例的狀態(tài)進行推理保證系統(tǒng)操作以合法的順序發(fā)生第63頁/共146頁問題和解決方案“浮腫的”控制器（BloatedControllers）如果設計得不合理，控制類內聚性不強-不聚焦并處理了太多領域的責任癥兆一個控制類接收所有的系統(tǒng)事件控制類自己處理了完成系統(tǒng)事件所需要的太多任務控制器有太多的屬性并維持了系統(tǒng)或領域的信息解決辦法增加控制器（使用用例控制器，非外觀控制器）設計控制器：把職責委派給其他對象第64頁/共146頁接口層并不處理系統(tǒng)事件

接口層到領域層之間所期望的耦合第65頁/共146頁接口層到領域層所不太期望的耦合第66頁/共146頁17.14：高內聚問題：怎樣保持對象是有重點的、可理解的、可管理的，并且能夠支持低耦合？內聚是對一個元素的責任之間的關系是否密切相關和集中的度量低內聚的類包含了很多無關的事情，或者承擔了太多的工作。它們有下面這些的問題:難以理解難以重用難以維護脆弱;常常受變化影響解決方案分配職責可保持較高的內聚性第67頁/共146頁示例我們需要創(chuàng)建(cash)Payment

的實例并將它與Sale關聯(lián)解決方案1假如有50個系統(tǒng)操作，都要由Register接收。如果Register要完成與每個操作都有關系的工作，它就會編成“臃腫的”、非內聚的對象。第68頁/共146頁解決方案2支持高內聚，又支持低耦合第69頁/共146頁討論這是一個需要時刻牢記的原則，就如同低耦合模式一樣高度內聚的類一般具有較少的方法，具有高度相關的功能，而且不完成太多的工作第70頁/共146頁另外一個經典原則：模塊化設計模塊化是將系統(tǒng)分解成一組內聚的、松散耦合的模塊的特性通過創(chuàng)建具有高內聚的方法和類來促進模塊化設計方法。在基本的對象級別上，我們?yōu)槊總€方法設計清晰和單獨的目標，并且把一組相關關注置于一個類中，以此來實現(xiàn)模塊化第71頁/共146頁內聚和耦合：“陰”和“陽”例如：考慮一個GUI窗口小部件類的做法：繪制窗口把數(shù)據(jù)存入數(shù)據(jù)庫調用遠程對象服務非內聚：（包含所有的功能）耦合高：（數(shù)據(jù)庫，遠程對象）第72頁/共146頁禁忌低內聚在某些情況下是可以接受的將SQL語句放入每一個類遵循了內聚模式。但是將SQL語句分離出來并歸并在一個類中更合理，因為它需要特殊的技術，由SQL專家專門處理。在分布應用中，為了改進性能，我們可以設置一個遠程操作setData

而不是分別設置setName,setSalary

和setHireDate.第73頁/共146頁第18使用GRASP的對象設計示例第74頁/共146頁18.1用例實現(xiàn)用例實現(xiàn)（use-caserealization）描述某個用例基于協(xié)作對象如何在設計模型中實現(xiàn)。UML圖是描述用例實現(xiàn)的常用語言?？梢栽谟美龑崿F(xiàn)的設計工作中應用對象設計的原則和模式。第75頁/共146頁18.2制品注釋SSD、系統(tǒng)操作、交互圖和用例實現(xiàn)考慮“處理銷售”用例的SSD所確定的系統(tǒng)操作和場景makeNewSaleenterItemendSalemakePayment如果使用通訊圖來描述用例實現(xiàn)，我們將繪制不同的通訊圖來表示對每個系統(tǒng)操作消息的處理。對于順序圖也同樣如此。第76頁/共146頁通信圖用于顯示用例實現(xiàn)第77頁/共146頁順序圖用于顯示用例實現(xiàn)第78頁/共146頁用例和用例實現(xiàn)用例是用例實現(xiàn)的首要輸入時刻記?。核涗浀男枨笫遣煌晟频淖尶蛻舯M量參與項目的整個過程第79頁/共146頁操作契約和用例實現(xiàn)有可能直接從用例的文字中設計用例實現(xiàn)對某些復雜系統(tǒng)操作而言，契約可以用于增加描述細節(jié)契約CO2:

enterItem操作:enterItem(ItemID:ItemID,quantity:integer)交叉引用:用例:處理銷售前置條件:有正在處理的銷售。后置條件:創(chuàng)建SalesLineItem的實例

sli-第80頁/共146頁對于每一個契約，我們會依據(jù)對相關用例文本的思考，完成后置條件的狀態(tài)變更，并設計消息的交互以滿足需求。第81頁/共146頁領域模型和用例實現(xiàn)選擇合適的責任分配依賴于領域模型但是用例實現(xiàn)可能引起領域模型的修改概念vs.設計類領域模型可以用以啟發(fā)我們在設計模型中定義軟件類并據(jù)此命名設計類必須來源于概念？完全不是。發(fā)現(xiàn)早期遺漏的新概念，同時也經常會虛構出一些軟件類，名稱和目的可能會與領域模型完全無關。第82頁/共146頁18.3下一步工作對NextGenPOS進行詳細討論。同樣對Monopoly案例研究進行詳細討論。第83頁/共146頁18.4NextGen迭代的用例實現(xiàn)初始和“啟動”用例啟動用例實現(xiàn)是設計語境，在該語境中要考慮創(chuàng)建大部分的“根”或生命期長的對象。準則：在編碼時，首先要考慮編寫啟動初始化的程序。OO設計建模時，最后考慮啟動初始化，直到發(fā)現(xiàn)哪些是真正需要被創(chuàng)建和初始化的。第84頁/共146頁設計啟動之前探討處理銷售用例實現(xiàn)如何設計makeNewSalemakeNewSale

系統(tǒng)操作發(fā)生于當收銀員在顧客到達后有東西要買，開始一筆新的買賣時第85頁/共146頁選擇控制類依據(jù)控制者模式，下面是一些選擇項:代表整個“系統(tǒng)”，設備或子系統(tǒng)Store：根對象Register：運行軟件特定設備POSSystem：整個系統(tǒng)名稱代表一個用例場景中系統(tǒng)事件的接收者或者處理者ProcessSaleHandlerProcessSaleSession在設計模型中，該Register是一個軟件對象。它不是一個真實的物理的收銀臺，而是一種軟件抽象，選擇這個名字可以減少領域和軟件概念之間的表示鴻溝.由于只存在少量的系統(tǒng)操作，因此Register就可以滿足要求。第86頁/共146頁創(chuàng)建新的Sale軟件對象Sale

必須被創(chuàng)建:Creator模式誰來創(chuàng)建它呢?Register（登記簿）是記錄（或登記）賬戶信息（例如銷售）的事物。Register是記錄Sale的類Register

創(chuàng)建它，然后與之關聯(lián)當Sale

創(chuàng)建后，它必須創(chuàng)建一個空的集合，以記錄所有的將來要被添加的SalesLineItem

實例第87頁/共146頁Register創(chuàng)建Sale，而Sale創(chuàng)建空集合。第88頁/共146頁如何設計enterItementerItem

系統(tǒng)操作發(fā)生于當收銀員輸入一個購買商品的itemID

和(可選)數(shù)量.契約CO2:enterItem操作:enterItem(itemID:ItemID,quantity:integer)交叉參考:用例：處理銷售前提條件:正在進行的銷售后置條件:創(chuàng)建了SalesLineItem的實例sli（創(chuàng)建實例）將Sli關聯(lián)到當前Sale（形成關聯(lián)）將sli.quantity數(shù)值為Quantity（修改屬性）基于itemID的匹配，將sli關聯(lián)到ProductSpecification（形成關聯(lián)）第89頁/共146頁選擇控制類系統(tǒng)操作消息enterItem的責任的處理如同makeNewSale一樣，采用Controller

模式繼續(xù)使用Register

作為控制器第90頁/共146頁是否要顯示商品項目的描述和價格使用的設計原則被稱為模型-視圖分離原則（Model-ViewSeparation）,

非GUI對象職責不應涉及輸出任務。盡管用例說明了在操作后描述和價格將被顯示，但是設計中在此時將忽略此情況第91頁/共146頁創(chuàng)建新的SalesLineItementerItem

契約的后置條件：顯示創(chuàng)建，初始化和與SalesLineItem的關聯(lián)。在領域模型中，Sale包含了SaleLineItem對象。因而，軟件Sale

也類似地包含軟件

SalesLineItem。通過Creator模式,發(fā)送makeLineItem消息到Sale來創(chuàng)建一個SaleLineItem。makeLineItem消息的參數(shù)包括Quantity。所以SaleLineItem可以記錄此值，SaleLineItem也需記錄與productDescription匹配的itemID值。第92頁/共146頁尋找ProductDescriptionSalesLineItem

要與匹配進入的itemID

的ProductDescription

建立關聯(lián)這意味著基于一個itemID

匹配，必須返回一個ProductDescription根據(jù)itemID的匹配，應該由誰負責了解ProductDescriptionNoCreator模式NoController模式信息專家模式？第93頁/共146頁信息專家模式：表明持有完成職責所需信息的對象應該負責上述職責。誰知道所有ProductDescription對象呢？依據(jù)領域模型，ProductCatalog邏輯上包含所有的ProductDescription.ProductCatalog是實現(xiàn)查找ProductDescription職責的最佳候選者。使用名為getProductDescription的方法實現(xiàn)這項查找工作。第94頁/共146頁ProductCatalog的可見性可見性:

一個對象“看見”或引用另一個對象的能力如果某對象要發(fā)送消息到另一個對象時，它必須擁有對接收消息對象的可見性。誰應該發(fā)送getProductDescription消息給ProductCategory來請求ProductDescription呢？假設在啟動用例的初始過程中，創(chuàng)建長生命期的Register和ProductCategory實例，并且存在永久關聯(lián)！Register擁有對ProductCategory的可見性，可以向它發(fā)送getProductDescription的消息第95頁/共146頁enterItem最終設計——協(xié)作圖第96頁/共146頁enterItem最終設計——類圖第97頁/共146頁從數(shù)據(jù)庫中檢索ProductDescription不可能把所有ProductDescription放在內存中。但是可以把它們放在關系數(shù)據(jù)庫或者對象數(shù)據(jù)庫中，然后按需檢索考慮到性能和容錯，一些ProductDescription可以緩存在客戶端的進程中。為了簡單起見，從數(shù)據(jù)庫中檢索的問題稍后討論，這里假設把所有的ProductDescription都裝在內存里。第98頁/共146頁如何設計endSale當收銀員按下表示商品條目輸入完畢的按鈕后，將會產生endSale

系統(tǒng)操作第99頁/共146頁選擇控制類繼續(xù)使用Register

作為控制器第100頁/共146頁設置Sale.isComplete屬性除非是控制器或者創(chuàng)建問題，否則信息專家模式應該是我們首先考慮的模式誰應該負責將Sale的屬性isComplete

設置為true呢?根據(jù)信息專家模式,應該是由Sale

本身完成。第101頁/共146頁計算銷售總額依據(jù)模型－視圖分離的設計原則，我們現(xiàn)在不應該關注如何顯示銷售總額，而是必須保證如何知道銷售總額目前沒有一個設計類知道銷售總額，要設計對象的交互來滿足此需求。除非是控制器或者創(chuàng)建問題，否則信息專家模式應該是我們首先要考慮應用的模式第102頁/共146頁分析過程：陳述職責：誰應該負責了解銷售總額？概括所需信息：銷售總額是所有銷售條目的小計之和銷售條目小計＝銷售條目數(shù)量×產品描述價格。列出實現(xiàn)此職責所需信息和了解這些信息的類。銷售總額所需要的信息信息專家ProductDescription.priceProductDescriptionSalesLineItem.quantitySalesLineItemAlltheSalesLineItemsinthecurrentSaleSale第103頁/共146頁誰應該負責計算總額？信息專家：因為Sale知道計算銷售總額所必需的所有SaleLineItem實例，所以Sale將承擔獲知總額的職責。銷售條目小計？信息專家：因為SaleLineItem知道其數(shù)量和與之關聯(lián)的ProductDescription，所以SaleLineItem承擔獲知小計的職責。ProductionDescription價格?信息專家：ProductionDescription自身，是它的一個屬性。更詳細的分析第104頁/共146頁設計Sale-getTotal并不是每一個交互圖都由系統(tǒng)操作消息(如enterItem或makeNewSale）開始，可以由設計者希望表示其交互的任何消息開始。第105頁/共146頁因為算法（通常）不是通過消息來說明的，那么可以通過在定義計算的圖中附加算法或約束來闡述計算的細節(jié)誰給Sale發(fā)送getTotal消息呢？最有可能是UI層對象第106頁/共146頁如何設計makePayment當收銀員輸入所支付的現(xiàn)金數(shù)額后，將發(fā)生makePayment

系統(tǒng)操作第107頁/共146頁創(chuàng)建Payment創(chuàng)建了Payment

的實例p(創(chuàng)建實例)這是一個創(chuàng)建職責.兩個候選者:Register在實際領域中，正是Register記錄賬戶信息Salesale對象頻繁使用Payment應用信息專家模式：誰是與初始數(shù)據(jù)相關的信息專家？

Register是接收系統(tǒng)操作makePayment消息的控制器，最早持有收款總額的信息?第108頁/共146頁準則：當存在多個可選設計時，應更深入地觀察可選設計所存在的內聚和耦合，以及未來可能存在的進化壓力。選擇具有良好內聚，耦合和在未來變化時能保持穩(wěn)定的設計第109頁/共146頁記錄Sale的日志如果采用后一種，SaleLedger還需要添加到領域模型中，它是現(xiàn)實領域中的概念專家模式：誰負責獲知所有已記錄的銷售并完成日志記錄工作？1：Store2：財務SalesLedger第110頁/共146頁假如堅持最初的計劃而使用Store第111頁/共146頁計算余額信息專家：誰負責獲知支付余額呢?Payment:知道所支付的現(xiàn)金總額Sale：知道銷售總額余額=所支付的現(xiàn)金總額-銷售總額兩個選擇Payment:它需要具有Sale的可見性，以便向Sale

請求銷售總額。它將增加整體設計的耦合度.Sale:它需要具有Payment的可見性，由于它是創(chuàng)建者，已經擁有Payment的可見性。因此并不增加總的耦合第112頁/共146頁第113頁/共146頁NextGen迭代1最終的DCD第114頁/共146頁如何將UI層連接到領域層常見設計:從應用的起始方法（例如，Java的main方法)中調用的初始化對象，同時創(chuàng)建UI對象和領域對象，并且將領域對象傳遞給UIUI對象從眾所周知的源提取領域對象，如一個負責創(chuàng)建領域對象的工廠對象第115頁/共146頁第一種方法：在Register中增加一個getTotal方法，再委派給Sale優(yōu)點：低耦合（UI只知道Register對象）缺點：擴展Register對象的接口，降低內聚度（非高內聚）第116頁/共146頁第二種方法：但是：內部或自身較高的耦合度不是問題，反之，與不穩(wěn)定元素的耦合才是真正問題所在。假設Sale是穩(wěn)定對象UI層直接發(fā)消息給Sale，產生較高的耦合第117頁/共146頁初始化和“啟動”用例系統(tǒng)需要StartUp,它包含了某些初始化系統(tǒng)操作。盡管這些startUp系統(tǒng)操作是最早要執(zhí)行的操作，但是在實際設計中要將該操作交互圖的開發(fā)推遲到其他所有系統(tǒng)操作的設計工作之后，這一實踐保證能夠發(fā)現(xiàn)所有相關初始化活動所需要的信息準則：最后完成初始化的設計第118頁/共146頁如何完成應用的啟動應用如何啟動和初始化與編程語言和操作系統(tǒng)有關常見的設計約定是創(chuàng)建一個初始領域對象或一組對等的初始領域對象一旦創(chuàng)建了初始領域對象（假設為單一的情況），該對象將負責創(chuàng)建其間接的子領域對象第119頁/共146頁Java應用中publicclassMain{publicstaticvoidmain(String[]args)//storeistheinitialdomainobject//ThestorecreatessomeotherdomainobjectsStorestore=newStore();Registerregister=store.getRegister();ProcessSaleJFrameframe=newProcessSaleJFrame(register); }}第120頁/共146頁選擇初始化領域對象初始化領域對象的類是什么?選擇位于或接近于領域對象包含或聚合層次中的根類作為初始領域對象。該類可能是外觀控制器，例如Register，也可能是容納所有或大部分其它對象的某些對象，例如Store。本應用中我們選擇Store作為初始對象。第121頁/共146頁設計Store-create()依據(jù)前面的設計工作:

Store,Register,ProductCatalogandProductDescription需要被創(chuàng)建ProductCatalog

需要與ProductDescription關聯(lián)Store

需要與ProductCatalog關聯(lián)Store

需要與Register關聯(lián)Register

需要與ProductCatalog關聯(lián)創(chuàng)建者模式：選擇Store創(chuàng)建ProductCatelog和Register；選擇ProductCatelog創(chuàng)建ProductDescription第122頁/共146頁領域模型和設計模型中對象類之間的多重性可能有所不同：軟件Store對象只創(chuàng)建一個Register對象，現(xiàn)實的商店擁有許多Pos終端第123頁/共146頁18.4Monopoly迭代的用例實現(xiàn)兩個系統(tǒng)操作：PlayGame和Initialize(orStartUP)第124頁/共146頁如何設計PlayGamePlayGame系統(tǒng)操作發(fā)生的時機是當玩游戲的人點擊UI圖標（例如點擊“開始游戲”的按鈕）請求游戲開始模擬，同時對結果進行查看。第125頁/共146頁選擇控制器類整個“系統(tǒng)”、根對象、特定設備或主要子系統(tǒng)MonopolyGameSystemMonopolyGame（MGame）表示用例場景中所有系統(tǒng)事件的接收者或處理者PlayMonopolyGameHandlerPlayMonopolyGameSession只有少量系統(tǒng)操作，并且外觀控制器不承擔太多的職責（也就是說不會變得非內聚），適宜選擇MonopolyGame第126頁/共146頁第127頁/共146頁游戲循環(huán)算法輪次（turn）游戲者投擲骰子并且移動棋子?；睾希╮ound）所有游戲者完成一個輪次。ForNroundsforeachPlayerpptakesaturn第128頁/共146頁誰來負責游戲循環(huán)？非控制器，非創(chuàng)建，信息專家模式？所需信息誰持有這些信息當前回合數(shù)目前還沒有相應的對象，但是為了實現(xiàn)低表示差異，將該職責分配給MonopolyGame是合理的。所有游戲者（這樣才能使每個游戲者完成其輪次）籍由領域模型，MonopolyGame是合適的候選者第129頁/共146頁使用了私有的內部的playRound方法：優(yōu)秀的OO方法設計提倡使用具有單一目標的小型方法，這樣可以在該方法級別上支持高內聚；playRound名字來源于領域詞匯，增加理解第130頁/共146頁誰來完成每一輪次的活動？每個輪次都包括擲骰子，并且根據(jù)骰子的總點數(shù)將棋子移動到相應的方格里。專家模式：現(xiàn)實中由游戲者完成其輪次的活動，所以將該職責分配給Player?違反高內聚和低耦合原則，使對象過于龐大。就如Pos領域中，Cashier軟件對象要完成幾乎所有的操作!對象設計要根據(jù)信息專家（和其他）原則將職責分配給眾多對象！第131頁/共146頁所需信息誰持有這些信息游戲者當前的位置（知道移動的起點）根據(jù)領域模型，Piece知道其所在的Square，Player知道代表它的Piece。所以根據(jù)LRG，Player軟件對象能夠知道其當前位置。兩個Die對象（用以拋擲并計算總點數(shù)）根據(jù)