北京北大青鳥學校學術部老師總結提供：
（1）所有數據都應該隱藏在所在的類的內部。
（2）類的使用者必須依賴類的共有接口，但類不能依賴它的使用者。
（3）盡量減少類的協議中的消息。
（4）實現所有類都理解的最基本公有接口[例如，拷貝操作（深拷貝和淺拷貝）、相等性判斷、正確輸出內容、從ASCII描述解析等等].
（5）不要把實現細節（例如放置共用代碼的私有函數）放到類的公有接口中。
如果類的兩個方法有一段公共代碼，那么就可以創建一個防止這些公共代碼的私有函數。
（6）不要以用戶無法使用或不感興趣的東西擾亂類的公有接口。
（7）類之間應該零耦合，或者只有導出耦合關系。也即，一個類要么同另一個類毫無關系，要么只使用另一個類的公有接口中的操作。
（8）類應該只表示一個關鍵抽象。
包中的所有類對于同一類性質的變化應該是共同封閉的。一個變化若對一個包影響，則將對包中的所有類產生影響，而對其他的包不造成任何影響 .（9）把相關的數據和行為集中放置。
設計者應當留意那些通過get之類操作從別的對象中獲取數據的對象。這種類型的行為暗示著這條經驗原則被違反了。
（10）把不相關的信息放在另一個類中（也即：互不溝通的行為）。
朝著穩定的方向進行依賴。
（11）確保你為之建模的抽象概念是類，而不只是對象扮演的角色。類應當統一地共享工作。
（13）在你的系統中不要創建全能類/對象。對名字包含Driver、Manager、System、Susystem的類要特別多加小心。
規劃一個接口而不是實現一個接口。
（14）對公共接口中定義了大量訪問方法的類多加小心。大量訪問方法意味著相關數據和行為沒有集中存放。
（15）對包含太多互不溝通的行為的類多加小心。
這個問題的另一表現是在你的應用程序中的類的公有接口中創建了很多的get和set函數。
（16）在由同用戶界面交互的Java面向對象模型構成的應用程序中，模型不應該依賴于界面，界面則應當依賴于模型。
（17）盡可能地按照現實世界建模（我們常常為了遵守系統功能分布原則、避免全能類原則以及集中放置相關數據和行為的原則而違背這條原則） .（18）從你的設計中去除不需要的類。
一般來說，我們會把這個類降級成一個屬性。
（19）去除系統外的類。
系統外的類的特點是，抽象地看它們只往系統領域發送消息但并不接受系統領域內其他類發出的消息。
（20）不要把操作變成類。質疑任何名字是動詞或者派生自動詞的類，特別是只有一個有意義行為的類�？紤]一下那個有意義的行為是否應當遷移到已經存在或者尚未發現的某個類中。
（21）我們在創建應用程序的分析模型時常常引入代理類。在設計階段，我們常會發現很多代理沒有用的，應當去除。
（22）盡量減少類的協作者的數量。
一個類用到的其他類的數目應當盡量少。
（23）盡量減少類和協作者之間傳遞的消息的數量。
（24）盡量減少類和協作者之間的協作量，也即：減少類和協作者之間傳遞的不同消息的數量。
（25）盡量減少類的扇出，也即：減少類定義的消息數和發送的消息數的乘積。
（26）如果類包含另一個類的對象，那么包含類應當給被包含的對象發送消息。也即：包含關系總是意味著使用關系。
（27）類中定義的大多數方法都應當在大多數時間里使用大多數數據成員。
（28）類包含的對象數目不應當超過開發者短期記憶的容量。這個數目常常是6.當類包含多于6個數據成員時，可以把邏輯相關的數據成員劃分為一組，然后用一個新的包含類去包含這一組成員。
（29）讓系統功能在窄而深的繼承體系中垂直分布。
（30）在實現語義約束時，最好根據類定義來實現。這常常會導致類泛濫成災，在這種情況下，約束應當在類的行為中實現，通常是在構造函數中實現，但不是必須如此。
北大青鳥學校學術部提供，未完待續
