類的設計

類要小

 

一個類的代碼行數少，當然好，我們這裏說的類要“小”，是指，一個類的設計第一原則是職責單一。

我是一個記性不好的人，代碼寫完不久，哪個類裏面包含哪些方法，很快就拋之九宵雲外了，如果類的職責唯一，那麼給這個類取名的時候就可以以這個類的職責名之，數周之後，當我要知道實現了某個職責的類在哪裏的時候，我只需要去尋找這個職責的名字即可。設想，如果某個系統裏存在著大量的萬能類，當我們想找某一職責的代碼時，如何尋找？我曾見過，某項目中某一個CPP文件的代碼行數大於兩萬行，幾乎所有參與維護的兄弟都叫苦不迭。

 

職責劃分之就近原則

 

在面向對象的設計中職責劃分是一個很重要的基本功，當我這個上層軟件開發的拼命學UML的時候，曾經有那麼一段時候忽略面向對象設計之本，以為工具才是重要的，非也！當我逐漸淡化面向對象設計的思想時，用的再好的工具畫出來的也是一片混亂的設計。

當我們說職責時，落實到具體行動中，就是實現這個職責的函數應該放在哪個類裏。一般的原則是，就近原則，所謂就近原則，就是將職責函數置於它所需要的信息所在的類中。這個我認為還是比較好理解的，其一，將職責函數與其相關的信息置於同一類中，職責函數獲取其所需信息方便；其二，這是一種歸類方法，比較易於記憶，易於記憶對軟件工程師而言永遠是首要考慮的問題，沒辦法，我們都是人類；基三，降低耦合，使得當前職責函數的變化或其不穩定性縮小在最小的範圍內。

 

類之整潔

    一個類的屬性不宜太多，這一規則也是為職責單一原則服務的，這裏說的屬性要少，也是對於職責而言的。

         一個類的屬性及其方法的排序一般按照：公共靜態屬性、私有靜態屬性、私有屬性、公共方法及私有方法的序列排序，公共屬性，不好意思，不建議大家使用。之所以私有方法置於最後 ，是因為私有方法一般是因公有方法而存在的。這種自上而下的排列方式是符合一般思維習慣的。