(零雨其蒙原創 轉載請注明)
2007
年
3
月
9
日星期五
?
第
23
章
迭代
2
：更多模式
在前面學習用例的時候，已經知道一個用例包含多個場景（主成功場景和擴展場景），由于
UP
倡導的是增量式開發，因此
Larman
給出了一些建議：在多次迭代中對同一用例的不同場景或特性進行工作，并且逐漸地擴展系統以最終實現對所有功能需求的處理。但是，不應該把一個場景分開在多次迭代中處理
,
一次迭代應該完成一個或多個端到端的場景。（
P294
）
即一個用例可以分多次迭代完成（每次至少完成一個場景），一個場景必須在一次迭代中完成
?
第
24
章
快速地更新分析
P297
使用
UP
的過程成熟標志是
，知道何時創建制品能夠帶來顯著價值，或是當遇到呆板的“完成作業”式的步驟時能夠較好地略過。
?
?
創建子類的準則
當遇到下列情況時，創建超類的概念子類：
1）
?
子類具有我們感興趣的額外屬性
2）
?
子類具有我們感興趣的額外關聯
3）
?
對子類概念的影響、處理、反應和操作與超類或其他子類有顯著的差異
?
?
關于子類和超類的其他準則（這些都是基于領域模型的討論，也就是在分析時觀點）
準則
：將超類聲明為抽象類。雖然這是與軟件無關的概念觀點，但是也是常用的
OO
準則，即所有軟件超類都是抽象的
準則
：在子類上附以超類名稱。（如超類是
Square
，則子類名就是
GoSquare
，
RegularSquare
等）
?
?
第
25
章
GRASP
：更多具有職責的對象
?
??
在這一章中
larman
介紹了前面沒有介紹過的四個
GRASP
模式：多態、間接性、純虛構和防止變異。經過這章的學習之后，
GRASP
的
9
個模式就學全了
~
按照
Larman
的說法，那時我們就擁有了討論設計的豐富、共享的詞匯。
?
Polymorphism
多態
問題：
如何處理基于類型的選擇？如何創建可插拔的軟件構件？
解決方案：
當相關選擇或行為隨類型（類）有所不同時，使用多態操作為變化的行為類型分配職責。
推理：
不要測試對象的類型，也不要使用條件邏輯來執行基于類型的不同選擇。
?
多態使我們不再使用條件分支語句來解決條件變化問題，前面在學習
Martin Fowler
的《重構》時我回憶了那個地磅系統中讓人惡心的
case
和
if-else
邏輯程序段，它制造了大量的重復和讓人感到對于業務過程的不解，從我個人的實踐來看，多態可以很好的解決這一問題，因為復雜性被封裝在了超類和子類的繼承關系中——那時我在做一個搜索引擎時，使用多態避免了傳統的使用條件分支語句來處理選擇搜索類別的問題（按商品名稱搜索，按作者搜索等類別），它有兩點好處：一個是簡潔，一個是清楚。可以很輕易的看出其邏輯關系。因此廢棄條件分支語句吧，在
[
問題
]
中
Larman
實際上已經給出了使用多態的好處，只不過用的是問句。
?
P305
當對象
A
持續需要對象
B
中的數據時，意味著：
1
）對象
A
不應該持有該數據；或
2
）對象
B
而不是對象
A
應該具有這一職責（基于專家模式）。
?
?
?
?
Pure Fabrication
純虛構
問題：
當你并不想違背高內聚和低耦合或其他目標，但是基于專家模式所提供的方案又不合適時，哪些對象應該承擔這一職責。
解決方案：
對人為制造的類分配一組高內聚的職責，該類并不代表問題領域的概念——虛構的事物，用以支持高內聚、低耦合和復用
?
?
P308-309
信息專家所支持的目標是，將職責與這些職責所需信息結合起來賦予同一個對象，以實現對低耦合的支持。如果濫用純虛構，會導致大量行為對象，其職責與執行職責所需的信息沒有結合起來，這樣會對耦合產生不良影響。其通常征兆是，對象內的大部分數據被傳遞給其他對象用以處理
（即該對象大量調用其它對象的方法來處理其自身的數據）。
?
?
Indirection
間接性
問題：
為了避免兩個或多個事物之間直接耦合，應該如何分配職責？如何使對象解耦合，以支持低耦合并提高復用性潛力？
解決方案：
將職責分配給中介對象，使其作為其他構件或服務之間的媒介，以避免它們之間的直接耦合。中介實現了其他構件之間的間接性。
?
Protected Variation
防止變異
問題：
如何設計對象、子系統和系統，使其內部的變化或不穩定不會對其他元素產生不良影響？
解決方案：
識別預計變化或不穩定之處，分配職責用以在這些變化之外創建穩定的接口。注意：這里使用的“接口”指的是廣泛意義上的訪問視圖，而不僅僅是諸如
Java
接口等字面含義。
?????????????