第七講對(duì)象設(shè)計(jì)(參考版)
2024-10-15 13:01本頁(yè)面
【正文】 控制器 控制器 分析和設(shè)計(jì) ? 需求和面向?qū)ο蠓治鲋攸c(diǎn)關(guān)注學(xué)習(xí)做正確的事。 ? 正常情況下，控制器應(yīng)當(dāng)把需要完成地工作委派給其他的對(duì)象。類似地，當(dāng)使用文字處理器的書(shū)寫者按下“拼寫檢查”按鈕時(shí)，他就發(fā)起了表示“執(zhí)行拼寫檢查”的系統(tǒng)事件 ? 控制器是 UI層之上的第一個(gè)對(duì)象，它負(fù)責(zé)接收和處理系統(tǒng)操作消息 控制器 ? 名稱：控制器（ Controller） ? 問(wèn)題：在 UI層之上首先接受和協(xié)調(diào)（“控制”）系統(tǒng)操作的對(duì)象是什么？ ? 解決方案：把職責(zé)分配給能代表以下選擇之一的類： ? 代表整個(gè)“系統(tǒng)”、“根對(duì)象”、運(yùn)行軟件的設(shè)備或主要子系統(tǒng)（這些是外觀控制器的所有變體）。這些是我們系統(tǒng)的主要輸入事件。 ? 在實(shí)踐中，內(nèi)聚程度不能脫離其他職責(zé)及其他原則（如專家和低耦合）單獨(dú)地考慮 GRASP之五控制器 ? 根據(jù) MVS原則，我們知道 UI對(duì)象不應(yīng)當(dāng)包含應(yīng)用邏輯或業(yè)務(wù)邏輯。這些元素包括類、子系統(tǒng)等等。利用這一原則來(lái)評(píng)估可選方案 GRASP之四高內(nèi)聚 ? 問(wèn)題： ? 怎樣保持對(duì)象是有重點(diǎn)的、可理解的、可管理的，并且能夠支持低耦合？ ? 從對(duì)象設(shè)計(jì)的角度上說(shuō)，內(nèi)聚（或更為專業(yè)地說(shuō)，是功能內(nèi)聚）是對(duì)元素職責(zé)的相關(guān)性和集中度的度量。具有低（或弱）耦合的元素不會(huì)包括類、子系統(tǒng)、系統(tǒng)等 ? 具有高（或強(qiáng)）耦合的類依賴于許多其他的類，這樣的類或許不是我們所需要的。在這些情況下，最好的方法是把創(chuàng)建職責(zé)委派給稱為具體工廠（ Concrete Factory）或抽象工廠（ Abstract Factory）的輔助類，而不是使用創(chuàng)建者所建議的類 GRASP之二信息專家 ? 名稱：信息專家（ Information Expert） ? 問(wèn)題：給對(duì)象分配職責(zé)的基本原則是什么？ ? 解決方案：把職責(zé)分配給具有完成該職責(zé)所需信息的那個(gè)類 信息專家 示例 Sale time Sales LineItem quantity Product Description description price itemID 1 1..* Contains 1 * Describedby 信息專家 示例 ? 問(wèn)題：哪個(gè)類應(yīng)當(dāng)負(fù)責(zé)了解銷售的總額？ ? 按照信息專家（ Information Expert）的建議，我們應(yīng)當(dāng)尋找具有確定總額所需信息的那個(gè)對(duì)象類。如此選擇是為了保持低耦合。 ? 相關(guān)模式或原則： ? 低耦合 ? 具體工廠和抽象工廠 ? 整體 部分描述了定義聚合對(duì)象的模式，它支持對(duì)構(gòu)件的封裝 創(chuàng)建者 討論 ? 創(chuàng)建者模式指導(dǎo)我們分配那些與創(chuàng)建對(duì)象有關(guān)的職責(zé)。為了完成該職責(zé)， Sale可能與其他對(duì)象協(xié)作，例如每個(gè) SaleLineItem對(duì)象發(fā)送 getSubtotal消息以獲取其小計(jì)金額 RDD ? RDD是思考 OO軟件設(shè)計(jì)的一般性隱喻 ? RDD使我們把 OO
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號(hào)-1