物件導向設計步驟二-------指定屬性的類型和可見度,分配職責(GRASP),訊息驅動,設計模式進行局部設計

標籤：指定屬性的類型和可見度   分配職責grasp   訊息驅動   設計模式進行局部設計   物件導向設計   

增加遺漏的屬性，指定屬性的類型和可見度：

在物件導向設計階段，需要對每個類進行詳細設計，不全過程中遺漏的屬性，並且確定每個屬性的資料類型，指定每個屬性的可見度；屬性的可見度指外部對象對屬性的存取權限，一般包括私人，保護和共有幾種類型；

在實際開發中，除了那些比較簡單且不常發生變化的屬性可以直接暴露給客戶以外，其他屬性最好設定為私人或者保護並且最好都能用GetXXX()和SetXXX（）等存取方法封裝一下

分配職責，定義執行每個職責的方法：

職責：是一個類或者類型的契約或者義務

物件導向系統中的類所承擔的職責可以分為兩大類：做型職責，自己要做某事，自己要為其他對象提供某種服務，發送訊息給其他對象一要求提供某種伏虎，控制和協調其他對象的服務；知道型職責，知道自己內部封裝了哪些資料，知道哪些對象和自己發生了關係

知道型職責是通過類內部封裝的屬性以及類間關係來體現的，所以，前面對於類的屬性和類間關係的討論分析就是我們在FishiGUI中的類中分配知道型職責的過程

做型職責是通過類的方法來實現的，為了分配做型職責，需要分析每一個類應該為其他類提供哪些服務，類本身包含哪些行為，應該履行那些義務，然後用類中相應的方法來實現這些職責

通用職責分配軟體模式（GRASP)：

通用職責分配軟體模式描述了在物件導向設計過程中把職責分配給系統中不同對象的有效經驗和基本原則；GRASP模式主要包括如下9中主要模式：

• 專家模式：應該將職責分配給資訊專家，即在分配一個職責時，應該瞭解履行該職責需要哪些資訊，這些資訊為哪個類或者哪些類所用夠。如果這些資訊為一個類所擁有，就把職責分配給它，如果為多個類所擁有，就為每個類分配一個職責，然後通過訊息傳遞和互動，使這些類協同完成該職責
• 建立者模式：按照建立者模式的要求，如果類A和類B滿足下列條件中的某一個A彙總了B對象；A包含了B對象；A的一個屬性記錄了B對象；A要經常使用B對象；B對象被建立時，A要傳遞初始化資料給B對象那麼我們就可以把建立B對象的職責分配給A對象，因為上述關係的存在，增加建立對象的職責不會增加系統的耦合性例在FishiGUI系統中，由於FG_TimerManager彙總了多個FG_Timer，因此定時器對象的建立和銷毀工作應該有FG_TimerManager來負責
• 低耦合：這裡的低耦合主要是類和類之間的關聯程度，即一個類知道其他類，依賴於其他類的強弱程度，類A和類B之間的耦合包括以下幾種情況：類A的一個方法的參數引用類B或者方法內定義了類B的一個局部變數；類A的一個屬性引用了類B的執行個體對象；類A的一個屬性彙總了類B的多個執行個體對象；類A是B間接或者直接的衍生類別。以上幾種耦合關係從上到下耦合程度越來越強，繼承是最強的一種偶合。
• 高內聚：內聚指的是一個類的各個職責之間的相關程度或集中程度，一般來說內聚度高的類應該只包含很少的方法樹，方法之間的關聯程度很高，每個方法承擔的工作量不是太大，任務也比較單一；當我們發現一個類擔負的任務太多，太雜就應該把一些職責分配給其他的類，這樣才能保證設計方案的高內聚
• 控制者模式：控制者模式要求把協調處理系統訊息的這則分配給不同的控制類
• 多態：當某一個職責在不同的衍生類別中表現為不同的行為時，我們就可以使用多態模式，即利用一個同名的多態方法把把該職責分配給不同的衍生類別，讓他們履行不同的行為
• 純虛構：可以虛構出一個人造的類，把一組蓋度內聚的職責分配給他，該人造類是虛構出來的事務，不代表現實世界中的任何實體，就是純虛構模式
• 中介者模式：把一些職責分配一個虛構的中介類，讓該中介類來協調多個類的協作關係，使用中介者類可以隔離耦合度過大的多個類，是容易發生變化的對象不會影響其他的對象
• 不要和陌生人講話：這個模式要求一個類盡量只是和它的直接對象互動，避免和間接對象互動，這樣，它就可以和最少的類產生耦合，使整個系統的耦合度保持最低。該準則要求，在一個對象的方法中，只能給下面的這些對象發送訊息：該對象自己；該方法的一個參數；該對象的一個屬性該對象的一個屬性集合中的一個元素；在該方法中建立的一個對象

對訊息驅動的系統，明確訊息傳遞方式：

物件導向設計很容易造成對象之間的關係數目日益膨脹，形成複雜的網狀結構。關係的複雜性同樣會導致類和對象間的耦合度增大，而訊息驅動的設計方案可以很好地皮面上述缺陷，特別是對於FishiGUI這樣的圖形化使用者介面架構而言，處理鍵盤滑鼠等作業系統傳來的訊息本來就是FishiGUI的職責之一，在物件導向技術裡，這些外部的軟硬體訊息和FishiGUI系統的內部通訊一道被映射為類和對象間的訊息傳遞（方法調用）。為了使用訊息驅動的設計方法，我們在FishiGUI中構造一個同一的訊息結構，以此來封裝作業系統發送給FishiGUI架構以及FishiGUI架構系統內部產生的各種訊息。所有這些訊息在作業系統適配層，架構層和應用程式層之間傳遞，驅動著整個系統正常運轉。（圖7-15中，層與層間的虛線箭頭代表訊息從下層想上層的傳遞，雙實線箭頭代表架構層通過函數調用的方式使用適配器子系統提供的服務，單實線箭頭代表應用程式層通過繼承和函數調用等方式使用架構層提供的服務）

利用設計模式進行局部設計：

在物件導向設計的過程中，應該盡量使用成熟的設計模式來最佳化模型的局部設計：

• 使用面板模式為適配器子系統添加一個統一的介面；
• 通過實施觀察者模式，是適配器子系統向架構層發送訊息時，無需依賴於架構層的具體實現；
• 對於系統中存在的只有唯一的對象執行個體的類，使用單件模式；
• 視窗元素的組織圖是一個典型的複合模式；
• 使用模板來實現彙總結構（如螢幕中包含多個視窗，視窗中包含多個空間..）並且使用迭代器模式來遍曆其中的每個字元素；使用建立型模式協助應用程式層建立控制項，使應用程式層能靈活地改變控制項的外觀；
• 使用職責鏈模式把訊息從螢幕對象分發到視窗 控制項等視窗元素；
• 把訊息從螢幕發送到視窗 控制項等視窗元素的過程，相當於把訊息從架構層傳送到了應用程式層，因此為了消除架構層到應用程式層的依賴性，首先使用了職責鏈模式提供的虛函數接受函數來實現多態性，隨後又利用模板方法模式提供的控制倒置特性對上述結構進行了最佳化；
• 在把適配器子系統移植到dos作業系統的過程中，我們使用了適配器模式以適應訊息管理機制完全不同的作業系統；
• 在設計應用程式層的商務邏輯時，我們使用MVC模式

物件導向設計步驟二-------指定屬性的類型和可見度,分配職責(GRASP),訊息驅動,設計模式進行局部設計