GRASP-基于職責(zé)設(shè)計對象課件

第17章GRASP：基于職責(zé)設(shè)計對象

GRASP:DesigningObjectswithResponsibilities1第17章GRASP：基于職責(zé)設(shè)計對象

GRASP:Des圖17-1制品關(guān)系（強調(diào)了對OO設(shè)計的影響2圖17-1制品關(guān)系（強調(diào)了對OO設(shè)計的影響2職責(zé)和方法

UML定義職責(zé)(Responsibility)為“類元的契約或義務(wù)。方法(Method)用來實現(xiàn)（履行）職責(zé)。一個職責(zé)可能要許多類和方法(method)來實現(xiàn)，也可能只要很少方法來實現(xiàn)，這是由職責(zé)的粒度(granularity)來決定的。3職責(zé)和方法UML定義職責(zé)(Responsibility)為職責(zé)可分成兩類：“認知”責(zé)（knowing）“行為”職責(zé)（doing）“知道”私有的封裝數(shù)據(jù)“知道”相關(guān)聯(lián)的對象“知道”能夠派生或計算出的事物“做”自身的一些事情。如創(chuàng)建一個對象或進行一次計算。“做”其它對象的初始化操作?？刂坪蛥f(xié)調(diào)其它對象的活動。4職責(zé)可分成兩類：“認知”責(zé)（knowing）“知道”私有職責(zé)和交互圖圖17-2職責(zé)與方法是相關(guān)的在UML制品（artifacts）中，通常是在建立交互圖的語境來考慮對象的職責(zé)分配，通過方法來實現(xiàn)職責(zé)。5職責(zé)和交互圖圖17-2職責(zé)與方法是相關(guān)的在UML制品（ar設(shè)計模式（Patterns）富有經(jīng)驗的面向?qū)ο蠹夹g(shù)專家（或其它軟件開發(fā)人員）為解決某些問題而設(shè)計的解決方案，可作為通用原則(GeneralPrinciples)和慣用法(Idioms)，用于指導(dǎo)軟件設(shè)計。如果將這些原則和慣用法以一種結(jié)構(gòu)化的形式加以描述，給出問題和解決方案，然后起一個名字。這就是設(shè)計模式(Patterns)。例如：模式名：信息專家（InformationExpert）問題：為了獲取某些信息，分配職責(zé)給對象的基本原則是什么？解決方案：將職責(zé)分配給信息專家--含有滿足職責(zé)所需信息的類。設(shè)計模式是一些針對特定問題的成功的解決方案6設(shè)計模式（Patterns）富有經(jīng)驗的面向?qū)ο驡oF關(guān)于設(shè)計模式的著作英文版于1994年出版這本書被認為是設(shè)計模式的“圣經(jīng)”，它描述了23個OO設(shè)計模式這本書的作者有四人ErichGamma,RichardHelm,RalphJohnson,JohnVlissides，因此被稱為GoF（GangofFour,四人幫）設(shè)計模式閱讀該書要有一定的OO設(shè)計和編程知識（C++）學(xué)習(xí)GRASP和基本GoF模式是本課程的關(guān)鍵目標7GoF關(guān)于設(shè)計模式的著作英文版于1994年出版學(xué)習(xí)GRASPGRASP：分配職責(zé)通用原則的模式

GRASP作為設(shè)計模式來描述對象設(shè)計和職責(zé)分配的基本原則。GRASP模式：創(chuàng)建者(Creator)信息專家(InformationExpert)低耦合(LowCoupling)控制器(Controller)高內(nèi)聚(HighCohesion)GeneralResponsibilityAssignmentSoftwarePattern8GRASP：分配職責(zé)通用原則的模式GRASP作為創(chuàng)建者（Creator）模式名：創(chuàng)建者問題：誰創(chuàng)建了A？解決方案(可被視作建議)：如果以下條件之一成立，則可以將創(chuàng)建類A實例的職責(zé)分配給類B。

B包含了A對象；B組成聚集了A；B記錄了A；B緊密地使用A；B具有A的初始化數(shù)據(jù)9創(chuàng)建者（Creator）模式名：創(chuàng)建者9問題：由誰創(chuàng)建Square對象圖17-3Monopoly迭代1的領(lǐng)域模型10問題：由誰創(chuàng)建Square對象圖17-3Monopoly迭圖17-4在動態(tài)模型中運用創(chuàng)建者模式圖17-5在設(shè)計模型的DCD中，Board與Square具有組成聚合關(guān)聯(lián)。我們在靜態(tài)模型中應(yīng)用了創(chuàng)建者在動態(tài)和靜態(tài)模型中應(yīng)用創(chuàng)建者模式11圖17-4在動態(tài)模型中運用創(chuàng)建者模式圖17-5在設(shè)計模型信息專家（InformationExpert）模式名：信息專家（或?qū)＜遥﹩栴}：給對象分配職責(zé)的基本原則是什么？解決方案(建議)：將職責(zé)分配給具有完成該職責(zé)所需信息的那個類12信息專家（InformationExpert）模式名：信息問題：如果給定鍵值，誰知道Square對象的相關(guān)信息圖17-6應(yīng)用專家模式13問題：如果給定鍵值，誰知道Square對象的相關(guān)信息圖17-低耦合（LowCoupling）模式名：低耦合問題：如何減少因變化產(chǎn)生的影響？解決方案(建議)：分配職責(zé)以使(不必要的)耦合保持在較低的水平。使用該原則對可選方案進行評估14低耦合（LowCoupling）模式名：低耦合14圖17-7評介耦合對設(shè)計影響此方案中Dog與Board都必須知道Square，而上一方案只有Board知道Square，所以上一方案耦合度更低。15圖17-7評介耦合對設(shè)計影響此方案中Dog與Board都必為什么期望低耦合因為低耦合往往能夠減少修改軟件所需的時間、工作量和缺陷。16為什么期望低耦合因為低耦合往往能夠減少修改軟件所需的時間、工創(chuàng)建者模式與低耦合創(chuàng)建者模式支持低耦合度,意味著具有較低的依賴關(guān)系和較高的重用機會。因為被創(chuàng)建的類很可能早已經(jīng)對創(chuàng)建者類可見（即在創(chuàng)建者類已有方法涉及被創(chuàng)建者類），耦合程度不會增加。17創(chuàng)建者模式與低耦合創(chuàng)建者模式支持低耦合度,意味著具有較低的依信息專家模式與低耦合信息專家模式支持低耦合度。因為信息專家模式把職責(zé)分配給擁有完成職責(zé)所需信息的對象。如果我們把職責(zé)分配給其他對象，則信息需要被這些對象共享會增加耦合度。18信息專家模式與低耦合信息專家模式支持低耦合度。18控制器（Controller）模式名：控制器問題：在UI層之上首先接收和協(xié)調(diào)(控制)系統(tǒng)操作的對象是什么？解決方案：將接收或處理系統(tǒng)事件消息的職責(zé)分派給代表下列事務(wù)的類：代表全部“系統(tǒng)”或“根對象”，如MonopolyGame對象代表運行軟件的設(shè)備，如Phone，BankCashMachine代表用例或會話出現(xiàn)。通常命名為<用例名>Handler，<用例名>Session。如，PlayMonopolyGameHandler。19控制器（Controller）模式名：控制器19問題：誰首先來處理playGame系統(tǒng)系統(tǒng)圖17-8Monopoly游戲的SSD。注意playGame操作20問題：誰首先來處理playGame系統(tǒng)系統(tǒng)圖17-8Mon根據(jù)模型與視圖分離原則，UI對象不應(yīng)當包括業(yè)務(wù)邏輯，應(yīng)該把請求委派給領(lǐng)域?qū)拥膶ο?。圖17-9誰是用于playGame系統(tǒng)操作的控制器21根據(jù)模型與視圖分離原則，UI對象不應(yīng)當包括業(yè)務(wù)邏輯，應(yīng)該把請如果只有少數(shù)幾個系統(tǒng)操作，可以選擇代表全部“系統(tǒng)”或“根對象”。圖17-10應(yīng)用控制器模式-使用MomopolyGame。所UI層與軟件對象的領(lǐng)域?qū)舆B接起來22如果只有少數(shù)幾個系統(tǒng)操作，可以選擇代表全部“系統(tǒng)”或“根對象高內(nèi)聚（HighCohesion）模式名：高內(nèi)聚問題：怎樣使對象保持有內(nèi)聚、可理解和可管理，同時具有支持低耦合的附加作用？解決方案：職責(zé)分配應(yīng)保持高內(nèi)聚，依此來評估備選方案。23高內(nèi)聚（HighCohesion）模式名：高內(nèi)聚23什么是高內(nèi)聚度（HighCohesion）高內(nèi)聚度是對一個類中的各個職責(zé)之間相關(guān)程度和集中程度的度量。一個具有高度相關(guān)職責(zé)的類并且這個類所能完成的工作量不是特別巨大，那么它就具有高內(nèi)聚度。包括兩個意思：不要給一個類分派太多的職責(zé)，在履行職責(zé)時盡量將部分職責(zé)分派給有能力完成的其它類去完成。不相關(guān)的職責(zé)不要分派給同一個類。24什么是高內(nèi)聚度（HighCohesion）高內(nèi)聚度是對一個圖17-11對比不同設(shè)計的內(nèi)聚程度左側(cè)的方案中，MonopolyGame對象自己完成全部工作

右側(cè)方案中，MonopolyGame為playGame請求對工作進行了委派25圖17-11對比不同設(shè)計的內(nèi)聚程度左側(cè)的方案中，MonopGRASP在NextGenPOS設(shè)計中的示例26GRASP在NextGenPOS設(shè)計中的示例26創(chuàng)建者模式示例：誰該負責(zé)創(chuàng)建SalesLineItem？圖17-12部分領(lǐng)域模型27創(chuàng)建者模式示例：誰該負責(zé)創(chuàng)建SalesLineItem？圖1Sale，因為它包含了SalesLineItem圖17-13創(chuàng)建SalesLineItem28Sale，因為它包含了SalesLineItem圖17-13信息專家示例：誰應(yīng)當負責(zé)了解銷售的總額圖17-14Sale的關(guān)聯(lián)答案：查找具有完成職責(zé)所需信息的類。1）如果DCD中存在相關(guān)類，則在DCD中查找2）否則查看領(lǐng)域模型，并嘗試利用(或擴充)它的表示，以激發(fā)相應(yīng)設(shè)計類的創(chuàng)建29信息專家示例：誰應(yīng)當負責(zé)了解銷售的總額圖17-14SaleSale的新職責(zé)圖17-15部分交互圖和類圖30Sale的新職責(zé)圖17-15部分交互圖和類圖30SalesLineItem的新職責(zé)圖17-16計算Sale的總額31SalesLineItem的新職責(zé)圖17-16計算SaleProductDescription的新職責(zé)圖17-17計算Sale的總額32ProductDescription的新職責(zé)圖17-17計低耦合模式示例：誰負責(zé)創(chuàng)建Payment圖17-18Register創(chuàng)建PaymentRegister記錄了PaymentSale具有初始化Payment的數(shù)據(jù)（支付總額），另支持是針對Sale進行的方案一（創(chuàng)建者模式）：33低耦合模式示例：誰負責(zé)創(chuàng)建Payment圖17-18Reg圖17-19Sale創(chuàng)建Payment方案二（創(chuàng)建者模式）：結(jié)論：方案二耦合度更低。禁忌：高耦合對于穩(wěn)定和普遍使用的元素而言不是問題同。如Java庫。34圖17-19Sale創(chuàng)建Payment方案二（創(chuàng)建者模式）控制器模式示例：

enterItem,endSale等系統(tǒng)操作的控制器是誰？圖17-20NextGenPOS應(yīng)用中的若干系統(tǒng)操作35控制器模式示例：

enterItem,endSale等系統(tǒng)操圖17-21哪個對象應(yīng)該是enterItem的控制器哪個對象應(yīng)該是enterItem的控制器36圖17-21哪個對象應(yīng)該是enterItem的控制器哪個對可能的選擇：

1.代表整個“系統(tǒng)”、“根對象”、裝置或子系統(tǒng)：

Register,POSSystem

2.代表用例場景中所有系統(tǒng)事件的接收者或處理者：

ProcessSaleHandler,ProcessSaleSession.圖17-22控制器的選擇37可能的選擇：

1.代表整個“系統(tǒng)”、“根對象”、裝置或子系不同方案的系統(tǒng)操作分配圖17-23系統(tǒng)操作的分配38不同方案的系統(tǒng)操作分配圖17-23系統(tǒng)操作的分配38關(guān)于控制器模式的討論控制器設(shè)計中的常見缺陷是分配的職責(zé)過多。這時，控制器會具有不良(低)內(nèi)聚，從而違反了高內(nèi)聚的原則準則：正常情況下，控制器應(yīng)當把需要完成的工作委派給其它對象。控制器只是協(xié)調(diào)或控制這些活動，本身并不完成大量工作。UP和Jacobson的原有對象方法中，有邊界對象(接口的抽象)，實體對象(領(lǐng)域軟件對象)和控制對象(控制器模式中的用例處理者)的概念?？刂破髂Ｊ降闹匾Y(jié)果是，UI對象和UI層不應(yīng)具有實現(xiàn)系統(tǒng)事件的職責(zé)。系統(tǒng)操作應(yīng)該在應(yīng)用邏輯層或領(lǐng)域?qū)油瓿伞?9關(guān)于控制器模式的討論控制器設(shè)計中的常見缺陷是分配的職責(zé)過多?？刂破髟赪ebUI和服務(wù)器的應(yīng)用在Web頁面中混入應(yīng)用邏輯是ASP.NET程序設(shè)計中常用的、脆弱的編程類型。服務(wù)器端的WebUI框架(如：Structs)包含Web-MVC(模型-視圖-控制器)模式的概念。Web-MVC中的控制器與GRASP控制器不同，前者是UI層的一部分，并且控制UI層的交互及頁面流；后者是領(lǐng)域?qū)拥囊徊糠?，它控制或協(xié)調(diào)工作請求的處理，它根本不知道所用的UI技術(shù)是什么？40控制器在WebUI和服務(wù)器的應(yīng)用在Web頁面中混入應(yīng)用邏輯UI層與控制器交互的編程示例使用JavaSwing的實現(xiàn)：富客戶端UIP222使用JavaStructs實現(xiàn)，客戶端瀏覽器和WebUIP22441UI層與控制器交互的編程示例使用JavaSwing的實現(xiàn)：浮腫的控制器在系統(tǒng)中只有一個簡單的控制器接收所有的系統(tǒng)事件，并且系統(tǒng)事件非常多?？刂破鞅旧韴?zhí)行許多實現(xiàn)系統(tǒng)事件必需的任務(wù)，而沒有把工作委托給別的類?？刂破鞅旧砭哂性S多屬性，并維護著系統(tǒng)或者領(lǐng)域中本應(yīng)該分布到其它對象的大量信息，或在別處可以找到的重復(fù)信息。42浮腫的控制器在系統(tǒng)中只有一個簡單的控制器接收所有的系統(tǒng)事件，避免浮腫的控制器的一些解決方案增加控制器。使用用例控制器，而不是外觀控制器航空預(yù)訂系統(tǒng)示例

設(shè)計控制器，使它把完成每個系統(tǒng)操作的職責(zé)委派給其它對象43避免浮腫的控制器的一些解決方案增加控制器。使用用例控制器，而界面層不處理系統(tǒng)事件-期望的圖17-24UI層到領(lǐng)域?qū)又g所期望的耦合44界面層不處理系統(tǒng)事件-期望的圖17-24UI層到領(lǐng)域?qū)又g界面層不處理系統(tǒng)事件-不期望的圖17-25UI層到領(lǐng)域?qū)铀惶谕鸟詈?5界面層不處理系統(tǒng)事件-不期望的圖17-25UI層到領(lǐng)域?qū)铀鶆?chuàng)建Payment類的對象的職責(zé)可以交給Sale類去完成。:Register履行makaPayment職責(zé)時要履行2個職責(zé)。高內(nèi)聚模式示例：makePayment職責(zé)的分配方案一：Register創(chuàng)建Payment圖17-26Register創(chuàng)建Payment46創(chuàng)建Payment類的對象的職責(zé)可以交給Sale類去完成。:創(chuàng)建Payment類的對象的職責(zé)委派給Sale類去完成。這樣，:Register履行makaPayment職責(zé)的負擔(dān)減輕了。只需履行1個職責(zé)方案二：Sale創(chuàng)建Payment圖17-27Sale創(chuàng)建Payment此方案既支持高內(nèi)聚又支持低耦合47創(chuàng)建Payment類的對象的職責(zé)委派給Sale類去完成。這樣演講完畢，謝謝觀看！演講完畢，謝謝觀看！第17章GRASP：基于職責(zé)設(shè)計對象

GRASP:DesigningObjectswithResponsibilities49第17章GRASP：基于職責(zé)設(shè)計對象

GRASP:Des圖17-1制品關(guān)系（強調(diào)了對OO設(shè)計的影響50圖17-1制品關(guān)系（強調(diào)了對OO設(shè)計的影響2職責(zé)和方法

UML定義職責(zé)(Responsibility)為“類元的契約或義務(wù)。方法(Method)用來實現(xiàn)（履行）職責(zé)。一個職責(zé)可能要許多類和方法(method)來實現(xiàn)，也可能只要很少方法來實現(xiàn)，這是由職責(zé)的粒度(granularity)來決定的。51職責(zé)和方法UML定義職責(zé)(Responsibility)為職責(zé)可分成兩類：“認知”責(zé)（knowing）“行為”職責(zé)（doing）“知道”私有的封裝數(shù)據(jù)“知道”相關(guān)聯(lián)的對象“知道”能夠派生或計算出的事物“做”自身的一些事情。如創(chuàng)建一個對象或進行一次計算?！白觥逼渌鼘ο蟮某跏蓟僮鳌？刂坪蛥f(xié)調(diào)其它對象的活動。52職責(zé)可分成兩類：“認知”責(zé)（knowing）“知道”私有職責(zé)和交互圖圖17-2職責(zé)與方法是相關(guān)的在UML制品（artifacts）中，通常是在建立交互圖的語境來考慮對象的職責(zé)分配，通過方法來實現(xiàn)職責(zé)。53職責(zé)和交互圖圖17-2職責(zé)與方法是相關(guān)的在UML制品（ar設(shè)計模式（Patterns）富有經(jīng)驗的面向?qū)ο蠹夹g(shù)專家（或其它軟件開發(fā)人員）為解決某些問題而設(shè)計的解決方案，可作為通用原則(GeneralPrinciples)和慣用法(Idioms)，用于指導(dǎo)軟件設(shè)計。如果將這些原則和慣用法以一種結(jié)構(gòu)化的形式加以描述，給出問題和解決方案，然后起一個名字。這就是設(shè)計模式(Patterns)。例如：模式名：信息專家（InformationExpert）問題：為了獲取某些信息，分配職責(zé)給對象的基本原則是什么？解決方案：將職責(zé)分配給信息專家--含有滿足職責(zé)所需信息的類。設(shè)計模式是一些針對特定問題的成功的解決方案54設(shè)計模式（Patterns）富有經(jīng)驗的面向?qū)ο驡oF關(guān)于設(shè)計模式的著作英文版于1994年出版這本書被認為是設(shè)計模式的“圣經(jīng)”，它描述了23個OO設(shè)計模式這本書的作者有四人ErichGamma,RichardHelm,RalphJohnson,JohnVlissides，因此被稱為GoF（GangofFour,四人幫）設(shè)計模式閱讀該書要有一定的OO設(shè)計和編程知識（C++）學(xué)習(xí)GRASP和基本GoF模式是本課程的關(guān)鍵目標55GoF關(guān)于設(shè)計模式的著作英文版于1994年出版學(xué)習(xí)GRASPGRASP：分配職責(zé)通用原則的模式

GRASP作為設(shè)計模式來描述對象設(shè)計和職責(zé)分配的基本原則。GRASP模式：創(chuàng)建者(Creator)信息專家(InformationExpert)低耦合(LowCoupling)控制器(Controller)高內(nèi)聚(HighCohesion)GeneralResponsibilityAssignmentSoftwarePattern56GRASP：分配職責(zé)通用原則的模式GRASP作為創(chuàng)建者（Creator）模式名：創(chuàng)建者問題：誰創(chuàng)建了A？解決方案(可被視作建議)：如果以下條件之一成立，則可以將創(chuàng)建類A實例的職責(zé)分配給類B。

B包含了A對象；B組成聚集了A；B記錄了A；B緊密地使用A；B具有A的初始化數(shù)據(jù)57創(chuàng)建者（Creator）模式名：創(chuàng)建者9問題：由誰創(chuàng)建Square對象圖17-3Monopoly迭代1的領(lǐng)域模型58問題：由誰創(chuàng)建Square對象圖17-3Monopoly迭圖17-4在動態(tài)模型中運用創(chuàng)建者模式圖17-5在設(shè)計模型的DCD中，Board與Square具有組成聚合關(guān)聯(lián)。我們在靜態(tài)模型中應(yīng)用了創(chuàng)建者在動態(tài)和靜態(tài)模型中應(yīng)用創(chuàng)建者模式59圖17-4在動態(tài)模型中運用創(chuàng)建者模式圖17-5在設(shè)計模型信息專家（InformationExpert）模式名：信息專家（或?qū)＜遥﹩栴}：給對象分配職責(zé)的基本原則是什么？解決方案(建議)：將職責(zé)分配給具有完成該職責(zé)所需信息的那個類60信息專家（InformationExpert）模式名：信息問題：如果給定鍵值，誰知道Square對象的相關(guān)信息圖17-6應(yīng)用專家模式61問題：如果給定鍵值，誰知道Square對象的相關(guān)信息圖17-低耦合（LowCoupling）模式名：低耦合問題：如何減少因變化產(chǎn)生的影響？解決方案(建議)：分配職責(zé)以使(不必要的)耦合保持在較低的水平。使用該原則對可選方案進行評估62低耦合（LowCoupling）模式名：低耦合14圖17-7評介耦合對設(shè)計影響此方案中Dog與Board都必須知道Square，而上一方案只有Board知道Square，所以上一方案耦合度更低。63圖17-7評介耦合對設(shè)計影響此方案中Dog與Board都必為什么期望低耦合因為低耦合往往能夠減少修改軟件所需的時間、工作量和缺陷。64為什么期望低耦合因為低耦合往往能夠減少修改軟件所需的時間、工創(chuàng)建者模式與低耦合創(chuàng)建者模式支持低耦合度,意味著具有較低的依賴關(guān)系和較高的重用機會。因為被創(chuàng)建的類很可能早已經(jīng)對創(chuàng)建者類可見（即在創(chuàng)建者類已有方法涉及被創(chuàng)建者類），耦合程度不會增加。65創(chuàng)建者模式與低耦合創(chuàng)建者模式支持低耦合度,意味著具有較低的依信息專家模式與低耦合信息專家模式支持低耦合度。因為信息專家模式把職責(zé)分配給擁有完成職責(zé)所需信息的對象。如果我們把職責(zé)分配給其他對象，則信息需要被這些對象共享會增加耦合度。66信息專家模式與低耦合信息專家模式支持低耦合度。18控制器（Controller）模式名：控制器問題：在UI層之上首先接收和協(xié)調(diào)(控制)系統(tǒng)操作的對象是什么？解決方案：將接收或處理系統(tǒng)事件消息的職責(zé)分派給代表下列事務(wù)的類：代表全部“系統(tǒng)”或“根對象”，如MonopolyGame對象代表運行軟件的設(shè)備，如Phone，BankCashMachine代表用例或會話出現(xiàn)。通常命名為<用例名>Handler，<用例名>Session。如，PlayMonopolyGameHandler。67控制器（Controller）模式名：控制器19問題：誰首先來處理playGame系統(tǒng)系統(tǒng)圖17-8Monopoly游戲的SSD。注意playGame操作68問題：誰首先來處理playGame系統(tǒng)系統(tǒng)圖17-8Mon根據(jù)模型與視圖分離原則，UI對象不應(yīng)當包括業(yè)務(wù)邏輯，應(yīng)該把請求委派給領(lǐng)域?qū)拥膶ο?。圖17-9誰是用于playGame系統(tǒng)操作的控制器69根據(jù)模型與視圖分離原則，UI對象不應(yīng)當包括業(yè)務(wù)邏輯，應(yīng)該把請如果只有少數(shù)幾個系統(tǒng)操作，可以選擇代表全部“系統(tǒng)”或“根對象”。圖17-10應(yīng)用控制器模式-使用MomopolyGame。所UI層與軟件對象的領(lǐng)域?qū)舆B接起來70如果只有少數(shù)幾個系統(tǒng)操作，可以選擇代表全部“系統(tǒng)”或“根對象高內(nèi)聚（HighCohesion）模式名：高內(nèi)聚問題：怎樣使對象保持有內(nèi)聚、可理解和可管理，同時具有支持低耦合的附加作用？解決方案：職責(zé)分配應(yīng)保持高內(nèi)聚，依此來評估備選方案。71高內(nèi)聚（HighCohesion）模式名：高內(nèi)聚23什么是高內(nèi)聚度（HighCohesion）高內(nèi)聚度是對一個類中的各個職責(zé)之間相關(guān)程度和集中程度的度量。一個具有高度相關(guān)職責(zé)的類并且這個類所能完成的工作量不是特別巨大，那么它就具有高內(nèi)聚度。包括兩個意思：不要給一個類分派太多的職責(zé)，在履行職責(zé)時盡量將部分職責(zé)分派給有能力完成的其它類去完成。不相關(guān)的職責(zé)不要分派給同一個類。72什么是高內(nèi)聚度（HighCohesion）高內(nèi)聚度是對一個圖17-11對比不同設(shè)計的內(nèi)聚程度左側(cè)的方案中，MonopolyGame對象自己完成全部工作

右側(cè)方案中，MonopolyGame為playGame請求對工作進行了委派73圖17-11對比不同設(shè)計的內(nèi)聚程度左側(cè)的方案中，MonopGRASP在NextGenPOS設(shè)計中的示例74GRASP在NextGenPOS設(shè)計中的示例26創(chuàng)建者模式示例：誰該負責(zé)創(chuàng)建SalesLineItem？圖17-12部分領(lǐng)域模型75創(chuàng)建者模式示例：誰該負責(zé)創(chuàng)建SalesLineItem？圖1Sale，因為它包含了SalesLineItem圖17-13創(chuàng)建SalesLineItem76Sale，因為它包含了SalesLineItem圖17-13信息專家示例：誰應(yīng)當負責(zé)了解銷售的總額圖17-14Sale的關(guān)聯(lián)答案：查找具有完成職責(zé)所需信息的類。1）如果DCD中存在相關(guān)類，則在DCD中查找2）否則查看領(lǐng)域模型，并嘗試利用(或擴充)它的表示，以激發(fā)相應(yīng)設(shè)計類的創(chuàng)建77信息專家示例：誰應(yīng)當負責(zé)了解銷售的總額圖17-14SaleSale的新職責(zé)圖17-15部分交互圖和類圖78Sale的新職責(zé)圖17-15部分交互圖和類圖30SalesLineItem的新職責(zé)圖17-16計算Sale的總額79SalesLineItem的新職責(zé)圖17-16計算SaleProductDescription的新職責(zé)圖17-17計算Sale的總額80ProductDescription的新職責(zé)圖17-17計低耦合模式示例：誰負責(zé)創(chuàng)建Payment圖17-18Register創(chuàng)建PaymentRegister記錄了PaymentSale具有初始化Payment的數(shù)據(jù)（支付總額），另支持是針對Sale進行的方案一（創(chuàng)建者模式）：81低耦合模式示例：誰負責(zé)創(chuàng)建Payment圖17-18Reg圖17-19Sale創(chuàng)建Payment方案二（創(chuàng)建者模式）：結(jié)論：方案二耦合度更低。禁忌：高耦合對于穩(wěn)定和普遍使用的元素而言不是問題同。如Java庫。82圖17-19Sale創(chuàng)建Payment方案二（創(chuàng)建者模式）控制器模式示例：

enterItem,endSale等系統(tǒng)操作的控制器是誰？圖17-20NextGenPOS應(yīng)用中的若干系統(tǒng)操作83控制器模式示例：

enterItem,endSale等系統(tǒng)操圖17-21哪個對象應(yīng)該是enterItem的控制器哪個對象應(yīng)該是enterItem的控制器84圖17-21哪個對象應(yīng)該是enterItem的控制器哪個對可能的選擇：

1.代表整個“系統(tǒng)”、“根對象”、裝置或子系統(tǒng)：

Register,POSSystem

2.代表用例場景中所有系統(tǒng)事件的接收者或處理者：

ProcessSaleHandler,ProcessSaleSession.圖17-22控制器的選擇85可能的選擇：

1.代表整個“系統(tǒng)”、“根對象”、裝置或子系不同方案的系統(tǒng)操作分配圖17-23系統(tǒng)操作的分配86不同方案的系統(tǒng)操作分配圖17-23系統(tǒng)操作的分配38關(guān)于控制器模式的討論控制器設(shè)計中的常見缺陷是分配的職責(zé)過多。這時，控制器會具有不良(低)內(nèi)聚，從而違反了高內(nèi)聚的原則準則：正常情況下，控制器應(yīng)當把需要完成的工作委派給其它對象?？刂破髦皇菂f(xié)調(diào)或控制這些活動，本身并不完成大量工作。UP和Jacobson的原有對象方法中，有邊界對象(接口的抽象)，