六十一條面向對象分析設計的經驗原則

你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起 。 ----- Arthur J.Riel

　　(1)所有資料都應該隐藏在所在的類的内部。

　　(2)類的使用者必須依賴類的共有接口，但類不能依賴它的使用者。

　　(3)盡量減少類的協定中的消息。

　　(4)實作所有類都了解的最基本公有接口[例如，拷貝操作(深拷貝和淺拷貝)、相等性判斷、正确輸出内容、從ASCII描述解析等等]。

　　(5)不要把實作細節(例如放置共用代碼的私有函數)放到類的公有接口中。

　　如果類的兩個方法有一段公共代碼，那麼就可以建立一個防止這些公共代碼的私有函數。

　　(6)不要以使用者無法使用或不感興趣的東西擾亂類的公有接口。

　　(7)類之間應該零耦合，或者隻有導出耦合關系。也即，一個類要麼同另一個類毫無關系，要麼隻使用另一個類的公有接口中的操作。

　　(8)類應該隻表示一個關鍵抽象。

　　包中的所有類對于同一類性質的變化應該是共同封閉的。一個變化若對一個包影響，則将對包中的所有類産生影響，而對其他的包不　　造成任何影響 .

　　(9)把相關的資料和行為集中放置。

　　設計者應當留意那些通過get之類操作從别的對象中擷取資料的對象。這種類型的行為暗示着這條經驗原則被違反了。

　　(10)把不相關的資訊放在另一個類中(也即：互不溝通的行為)。

　　朝着穩定的方向進行依賴.

　　(11)確定你為之模組化的抽象概念是類，而不隻是對象扮演的角色。

　　(12)在水準方向上盡可能統一地分布系統功能，也即：按照設計，頂層類應當統一地共享工作。

　　(13)在你的系統中不要建立全能類/對象。對名字包含Driver、Manager、System、Susystem的類要特别多加小心。

　　規劃一個接口而不是實作一個接口。

　　(14)對公共接口中定義了大量通路方法的類多加小心。大量通路方法意味着相關資料和行為沒有集中存放。

　　(15)對包含太多互不溝通的行為的類多加小心。

　　這個問題的另一表現是在你的應用程式中的類的公有接口中建立了很多的get和set函數。

　　(16)在由同使用者界面互動的面向對象模型構成的應用程式中，模型不應該依賴于界面，界面則應當依賴于模型。

　　(17)盡可能地按照現實世界模組化(我們常常為了遵守系統功能分布原則、避免全能類原則以及集中放置相關資料和行為的原則而違背　　　　這條原則) 。

　　(18)從你的設計中去除不需要的類。

　　一般來說，我們會把這個類降級成一個屬性。

　　(19)去除系統外的類。

　　系統外的類的特點是，抽象地看它們隻往系統領域發送消息但并不接受系統領域内其他類發出的消息。

　　(20)不要把操作變成類。質疑任何名字是動詞或者派生自動詞的類，特别是隻有一個有意義行為的類。考慮一下那個有意義的行為是　　否應當遷移到已經存在或者尚未發現的某個類中。

　　(21)我們在建立應用程式的分析模型時常常引入代理類。在設計階段，我們常會發現很多代理沒有用的，應當去除。

　　(22)盡量減少類的協作者的數量。

　　一個類用到的其他類的數目應當盡量少。

　　(23)盡量減少類和協作者之間傳遞的消息的數量。

　　(24)盡量減少類和協作者之間的協作量，也即：減少類和協作者之間傳遞的不同消息的數量。

　　(25)盡量減少類的扇出，也即：減少類定義的消息數和發送的消息數的乘積。

　　(26)如果類包含另一個類的對象，那麼包含類應當給被包含的對象發送消息。也即：包含關系總是意味着使用關系。

　　(27)類中定義的大多數方法都應當在大多數時間裡使用大多數資料成員。

　　(28)類包含的對象數目不應當超過開發者短期記憶的容量。這個數目常常是6。

　　當類包含多于6個資料成員時，可以把邏輯相關的資料成員劃分為一組，然後用一個新的包含類去包含這一組成員。

　　(29)讓系統功能在窄而深的繼承體系中垂直分布。

　　(30)在實作語義限制時，最好根據類定義來實作。這常常會導緻類泛濫成災，在這種情況下，限制應當在類的行為中實作，通常是在　　構造函數中實作，但不是必須如此。

　　(31)在類的構造函數中實作語義限制時，把限制測試放在構造函數領域所允許的盡量深的包含層次中。

　　(32)限制所依賴的語義資訊如果經常改變，那麼最好放在一個集中式的第3方對象中。

　　(33)限制所依賴的語義資訊如果很少改變，那麼最好分布在限制所涉及的各個類中。

　　(34)類必須知道它包含什麼，但是不能知道誰包含它。

　　(35)共享字面範圍(也就是被同一個類所包含)的對象互相之間不應當有使用關系。

　　(36)繼承隻應被用來為特化層次結構模組化。

　　(37)派生類必須知道基類，基類不應該知道關于它們的派生類的任何資訊。

　　(38)基類中的所有資料都應當是私有的，不要使用保護資料。

　　類的設計者永遠都不應該把類的使用者不需要的東西放在公有接口中。

　　(39)在理論上，繼承層次體系應當深一點，越深越好。

　　(40)在實踐中，繼承層次體系的深度不應當超出一個普通人的短期記憶能力。一個廣為接受的深度值是6。

　　(41)所有的抽象類都應當是基類。

　　(42)所有的基類都應當是抽象類。

　　(43)把資料、行為和/或接口的共性盡可能地放到繼承層次體系的高端。

　　(44)如果兩個或更多個類共享公共資料(但沒有公共行為)，那麼應當把公共資料放在一個類中，每個共享這個資料的類都包含這個類。

　　(45)如果兩個或更多個類有共同的資料和行為(就是方法)，那麼這些類的每一個都應當從一個表示了這些資料和方法的公共基類繼承。

　　(46)如果兩個或更多個類共享公共接口(指的是消息，而不是方法)，那麼隻有他們需要被多态地使用時，他們才應當從一個公共基類　　繼承。

　　(47)對對象類型的顯示的分情況分析一般是錯誤的。在大多數這樣的情況下，設計者應當使用多态。

　　(48)對屬性值的顯示的分情況分析常常是錯誤的。類應當解耦合成一個繼承層次結構，每個屬性值都被變換成一個派生類。

　　(49)不要通過繼承關系來為類的動态語義模組化。試圖用靜态語義關系來為動态語義模組化會導緻在運作時切換類型。

　　(50)不要把類的對象變成派生類。對任何隻有一個執行個體的派生類都要多加小心。

　　(51)如果你覺得需要在運作時刻建立新的類，那麼退後一步以認清你要建立的是對象。現在，把這些對象概括成一個類。

　　(52)在派生類中用空方法(也就是什麼也不做的方法)來覆寫基類中的方法應當是非法的。

　　(53)不要把可選包含同對繼承的需要相混淆。把可選包含模組化成繼承會帶來泛濫成災的類。

　　(54)在建立繼承層次時，試着建立可複用的架構，而不是可複用的元件。

　　(55)如果你在設計中使用了多重繼承，先假設你犯了錯誤。如果沒犯錯誤，你需要設法證明。

　　(56)隻要在面向對象設計中用到了繼承，問自己兩個問題：(1)派生類是否是它繼承的那個東西的一個特殊類型？(2)基類是不是派生　　類的一部分？

　　(57)如果你在一個面向對象設計中發現了多重繼承關系，確定沒有哪個基類實際上是另一個基類的派生類。

　　(58)在面向對象設計中如果你需要在包含關系和關聯關系間作出選擇，請選擇包含關系。

　　(59)不要把全局資料或全局函數用于類的對象的薄記工作。應當使用類變量或類方法。

　　(60)面向對象設計者不應當讓實體設計準則來破壞他們的邏輯設計。但是，在對邏輯設計作出決策的過程中我們經常用到實體設計準　　則。

　　(61)不要繞開公共接口去修改對象的狀态。