(14)對公共接口中定義了大量訪問方法的類多加小心。大量訪問方法意味著相關數據和行為沒有集中存放。
(15)對包含太多互不溝通的行為的類多加小心。
這個問題的另一表現是在你的應用程序中的類的公有接口中創建了很多的get和set函數。
(16)在由同用戶界面交互的面向對象模型構成的應用程序中，模型不應該依賴于界面，界面則應當依賴于模型。
(17)盡可能地按照現實世界建模(我們常常為了遵守系統功能分布原則、避免全能類原則以及集中放置相關數據和行為的原則而違背 這條原則) 。
(18)從你的設計中去除不需要的類。
一般來說，我們會把這個類降級成一個屬性。
(19)去除系統外的類。
系統外的類的特點是，抽象地看它們只往系統領域發送消息但并不接受系統領域內其他類發出的消息。
(20)不要把操作變成類。質疑任何名字是動詞或者派生自動詞的類，特別是只有一個有意義行為的類�？紤]一下那個有意義的行為是 否應當遷移到已經存在或者尚未發現的某個類中。
(21)我們在創建應用程序的分析模型時常常引入代理類。在設計階段，我們常會發現很多代理沒有用的，應當去除。
(22)盡量減少類的協作者的數量。
一個類用到的其他類的數目應當盡量少。
(23)盡量減少類和協作者之間傳遞的消息的數量。
(24)盡量減少類和協作者之間的協作量，也即：減少類和協作者之間傳遞的不同消息的數量。
(25)盡量減少類的扇出，也即：減少類定義的消息數和發送的消息數的乘積。
(26)如果類包含另一個類的對象，那么包含類應當給被包含的對象發送消息。也即：包含關系總是意味著使用關系。
(27)類中定義的大多數方法都應當在大多數時間里使用大多數數據成員。
(28)類包含的對象數目不應當超過開發者短期記憶的容量。這個數目常常是6。
當類包含多于6個數據成員時，可以把邏輯相關的數據成員劃分為一組，然后用一個新的包含類去包含這一組成員。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
