思維導圖
介紹
accessor:訪問者,存儲器——在本文翻譯為“函數”
dumb:啞
domain class:用以處理業務邏輯
presentation class:用以處理”數據表現形式“
business logic:業務邏輯
unidirectional:單向的
bidirectional:雙向的
collection:群集
Self Encapsulate Field 狀況:如果Client直接訪問值域,會造成Client與值域之間的耦合關系逐漸變得笨拙,那麼為這個值域建立取值/設置函數,並且只以這些函數來訪問。
動機:
“間接訪問變量”:支持更靈活的數據獲取方式,如lazy Initialization(意思是只有用到值時,才對它進行初始化。)
“直接訪問變量”:代碼比較容易閱讀,不需要停下來說:“啊,這只是個取值函數”。
選擇:1、代碼規范,按照團隊中大多數人的做法去做。
2、個人比較喜歡“直接訪問變量”,直到這種方式帶來麻煩為止。
martin(作者)的例子:你想獲取superclass中的field,卻又想在subclass中將該field改為計算後的值,這就最該使用Self Encapsulate Field。
我自己的例子:我一般會把field設置成private,如果外部變量,需要用到此field的時候,我就會用Self Encapsulate Field。或者field的值有變化的時候,用Self Encapsulate Field。
動機:
開發初期,我們也許會使用基本數據類型表示簡單的行為。例如:你可能會用一個字符串表示電話號碼,但是隨後可能會出現電話號碼的“格式化“,”驗證“,”抽取區號“之類的特殊行為。——這時候我們就需要一個新類。
Replace Array with Object 狀況:你有一個數組,數組中的元素各自代表不同的東西,那麼以對象替換數組,對於數組中的每個元素,以一個值域表示之。動機:
數組常用於一組相似對象。如果數組中的元素不同,很難明白數組中的第一個元素是人名這樣的約定。對象就不同了,可以通過值域名稱和函數名稱傳達這樣的信息。——這樣無須死記,無須注釋。
Encapsulate Field 狀況:如果你的class中有一個public值域,那麼將它聲明為pirvate,並提供相應的訪問函數。動機:
面向對象的原則之一就是封裝(Encapsulate)或者稱為”數據隱藏“。按照此原測,你絕不應該把數據聲明為public。 ——public 數據被看成是一種不好的做法。 ——如果封裝了,代碼的修改就會比較簡單,因為都集中在一個地方。 一個函數除了訪問函數(getting/setting)外,不提供其他行為,它終究只是一個dumb class(啞類)。這類class不能獲得對象技術的優勢。——解決啞類的方法是Move Method輕快的將它們移到新對象去。 conclusion 我希望能把我理解的東西與大家分享,歡迎大家提出寶貴意見。