你不必嚴格遵守這些原則違背它們也不會被處以宗教刑罰但你應當把這些原則看成警鈴若違背了其中的一條那麼警鈴就會響起 Arthur JRiel
()所有數據都應該隱藏在所在的類的內部
()類的使用者必須依賴類的共有接口但類不能依賴它的使用者
()盡量減少類的協議中的消息
()實現所有類都理解的最基本公有接口[例如拷貝操作(深拷貝和淺拷貝)相等性判斷正確輸出內容從ASCII描述解析等等
()不要把實現細節(例如放置共用代碼的私有函數)放到類的公有接口中
如果類的兩個方法有一段公共代碼那麼就可以創建一個防止這些公共代碼的私有函數
()不要以用戶無法使用或不感興趣的東西擾亂類的公有接口
()類之間應該零耦合或者只有導出耦合關系也即一個類要麼同另一個類毫無關系要麼只使用另一個類的公有接口中的操作
()類應該只表示一個關鍵抽象
包中的所有類對於同一類性質的變化應該是共同封閉的一個變化若對一個包影響則將對包中的所有類產生影響而對其他的包不造成任何影響
()把相關的數據和行為集中放置
設計者應當留意那些通過get之類操作從別的對象中獲取數據的對象這種類型的行為暗示著這條經驗原則被違反了
()把不相關的信息放在另一個類中(也即互不溝通的行為)
朝著穩定的方向進行依賴
()確保你為之建模的抽象概念是類而不只是對象扮演的角色
()在水平方向上盡可能統一地分布系統功能也即按照設計頂層類應當統一地共享工作
()在你的系統中不要創建全能類/對象對名字包含DriverManagerSystemSusystem的類要特別多加小心
規劃一個接口而不是實現一個接口
()對公共接口中定義了大量訪問方法的類多加小心大量訪問方法意味著相關數據和行為沒有集中存放
()對包含太多互不溝通的行為的類多加小心
這個問題的另一表現是在你的應用程序中的類的公有接口中創建了很多的get和set函數
()在由同用戶界面交互的面向對象模型構成的應用程序中模型不應該依賴於界面界面則應當依賴於模型
()盡可能地按照現實世界建模(我們常常為了遵守系統功能分布原則避免全能類原則以及集中放置相關數據和行為的原則而違背這條原則)
()從你的設計中去除不需要的類
一般來說我們會把這個類降級成一個屬性
()去除系統外的類
系統外的類的特點是抽象地看它們只往系統領域發送消息但並不接受系統領域內其他類發出的消息
()不要把操作變成類質疑任何名字是動詞或者派生自動詞的類特別是只有一個有意義行為的類考慮一下那個有意義的行為是 否應當遷移到已經存在或者尚未發現的某個類中
()我們在創建應用程序的分析模型時常常引入代理類在設計階段我們常會發現很多代理沒有用的應當去除
()盡量減少類的協作者的數量
一個類用到的其他類的數目應當盡量少
()盡量減少類和協作者之間傳遞的消息的數量
()盡量減少類和協作者之間的協作量也即減少類和協作者之間傳遞的不同消息的數量
()盡量減少類的扇出也即減少類定義的消息數和發送的消息數的乘積
()如果類包含另一個類的對象那麼包含類應當給被包含的對象發送消息也即包含關系總是意味著使用關系
()類中定義的大多數方法都應當在大多數時間裡使用大多數數據成員
()類包含的對象數目不應當超過開發者短期記憶的容量這個數目常常是
當類包含多於個數據成員時可以把邏輯相關的數據成員劃分為一組然後用一個新的包含類去包含這一組成員
()讓系統功能在窄而深的繼承體系中垂直分布
()在實現語義約束時最好根據類定義來實現這常常會導致類泛濫成災在這種情況下約束應當在類的行為中實現通常是在 構造函數中實現但不是必須如此
()在類的構造函數中實現語義約束時把約束測試放在構造函數領域所允許的盡量深的包含層次中
()約束所依賴的語義信息如果經常改變那麼最好放在一個集中式的第方對象中
()約束所依賴的語義信息如果很少改變那麼最好分布在約束所涉及的各個類中
()類必須知道它包含什麼但是不能知道誰包含它
()共享字面范圍(也就是被同一個類所包含)的對象相互之間不應當有使用關系
[] []
From:http://tw.wingwit.com/Article/program/PHP/201311/21393.html
