?? 《c++編程思想》-- 第1章 筆記(5).txt
字號:
作者:rick1126
email: rickzhang@sina.com
日期:7/15/2001 9:31:34 AM
1.5 其他方法
1.5.1 Booch 方法
最早的, 最基本和最廣泛被引用的一個方法. 焦點是在OOP的淚, 方法和繼承和單獨性能上.
【在抽象的特定層上確定類和對象】
. 使用自然語言聲明問題和解, 并且確定關鍵特性.
【確定它們的語義】
. 在相應的抽象層上定義類, 如果計劃建立一個類, 我們應當確定類的相應觀眾或者使用者
. 應當具備主題屬性和客體屬性應對不同層次的使用者
【確定它們之間的關系】
. 定義一個類如何與其他類互相作用.
. 強每一個類的信息制作表格: 使用類, 責任和協作( Class, Responsibility, Collaboration, CRC )卡片
責任 - 發送和接收的消息
協作 - 引用關系
. 必要性: 如果不能在一個卡片上明確表述類的所有內容就表示這個類過于復雜, 這個和我們之前提到的簡單化原則是不適合的
. 要求卡片內部不涉及主要技術改革的解決方法, 對于每一個人都是可用的
【實現類】
【反復設計】
1.5.2 責任驅動的設計 ( RDD )
也是使用CRC卡片, 重點在于責任的授權, 而不是外觀.
使用Booch方法, 雇員 - 銀行雇員 - 銀行經理 ==> 這里遵循責任, 協作關系的角度
使用RDD方法, 經理 - 金融經理 - 銀行經理 ==> 著重在責任, 即從職務角度不加區分
【內容】
. 數據和狀態
每一個類的數據變量和狀態變量的描述
. 數據池和數據源
哪一個類產生數據, 哪一個類處理數據 ( 生產者 - 消費者 )
. 觀察者或者觀點
觀點和觀察者類, 用以隔離硬件依賴. 觀點是邏輯產物, 觀察者則是產生觀點的主體.
. 輔助工具或者幫助器
輔助工具或者幫助類, 類似虛函數表和處理方法構成一個幫助類
1.5.3 對象建模技術 ( OMT )
【對于Booch和RDD的發展】
. Boonch方法強調類的功能表現, 簡單地定義它們作為自然語言的輪廓
. RDD強調類的責任表現
. OMT使用詳細繪制圖表的方法, 不僅描述類, 而且還描述系統的各種狀態
【OMT的描述】
. 對象模型 "什么" ==> 對象圖表, 類似Booch和RDD的對象模型, 對象通過責任相互關聯
. 動態模型 "何時" ==> 狀態圖表, 描寫了系統與時間有關的狀態, 不同狀態通過轉變相關聯
. 功能模型 "如何" ==> 數據流程表, 跟蹤數據流, 在程序的最低層行, 實際的工作時通過使用過程完成的, 因此程序的低層行為最好通過畫數據流理解
〖個人理解〗
其實前面的幾種方法都是在對象之間的關系上面側重不同. Booch使用CRC卡片, 形象化的給出了對象的描述. 比較完善了給出了對象的幾個側重點 -- 類, 責任( 處理和發送的消息 ), 協作( 相互關系 ). Booch 著重在于類的功能表現, RDD則關鍵注重責任即使用者的角度, OMT重視各個類型之間的關系; 所以焦點就是各個類的繼承關系的不同. 舉例如下 -- 有一個銀行系統
在Booch看來, 分類繼承層次為: 一般職員 - 銀行職員 - 銀行經理; 繼承準則就是各自的"外觀" -- 即階層不同
在RDD看來, 分類繼承則為: 一般職員 - 銀行職員; 經理 - 金融經理 - 銀行經理; 繼承準則在于"責任" -- 處理的消息的逐步特殊化
對于OMT還需要給出各種圖表, 自然這和我先前談到的自然語言應該不是矛盾的, 是應該在各個部門達成共識以后的一些輔助性的圖標, 修改的時候應當還是基于自然語言的語義描述角度.
其實牽強的對于上述方法進行比較我想也是不公平的, 因為出現的時間不同嘛, 關鍵時繼承原則應該統一.
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -