北京北大青鳥學校學術部老師總結提供：
（31）在類的構造函數中實現語義約束時，把約束測試放在構造函數領域所允許的盡量深的包含層次中。
（32）Java面向對象中，約束所依賴的語義信息如果經常改變，那么最好放在一個集中式的第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）只要在Java面向對象設計中用到了繼承，問自己兩個問題：（1）派生類是否是它繼承的那個東西的一個特殊類型？（2）基類是不是派生類的一部分？
（57）如果你在一個面向對象設計中發現了多重繼承關系，確保沒有哪個基類實際上是另一個基類的派生類。
（58）在面向對象設計中如果你需要在包含關系和關聯關系間作出選擇，請選擇包含關系。
（59）不要把全局數據或全局函數用于類的對象的薄記工作。應當使用類變量或類方法。
（60）Java面向對象設計者不應當讓物理設計準則來破壞他們的邏輯設計。但是，在對邏輯設計作出決策的過程中我們經常用到物理設計準則。
（61）不要繞開公共接口去修改對象的狀態
文章來源：北京北大青鳥學術部老師
