物件健身操 Thought Works文集

最近看到了一本非常值得閱讀的書《軟體開發沉思錄--thought works

文集》，

13篇美文薈萃軟體開發精華，來自軟體界思想領袖們的經驗心得，為你開啟敏捷開發之門。其中有一篇文章非常經典，讓我愛不釋手。現在我把裡面的部分思想摘錄於此，以此來警戒自己。

九步邁向優秀軟體設計：

物件導向程式設計一直在鼓勵我們擺脫過程式**的桎梏，幫助我們以累加的方式編寫**，並重用已有的元件。優秀設計背後的核心概念其實並不高深：內聚性、松耦、零重複、封裝、可測試性、可讀性以及單一職責。作者給出了一系列實踐規則，讓我們將良好的物件導向設計原則變得更加具體。

規則1：方法只使用一級縮排

龐大的方法通常缺少內聚性。乙個常見的原則是將方法的行數控制在5

行之類。每個方法都只關注一件事，而它們所在的淚也只做一件事。

規則2：拒絕

else

關鍵字

層層巢狀的條件判斷，連綿數頁的case

語句。對於簡單的條件判斷，我們可以使用「衛語句」和「提前返回」替換它。

規則3：封裝所有的原生型別和字串

規則4：一行**只有乙個「

.」運算子

一行包含了多個「.

」的**，很難判斷出乙個行為的職責應該由哪個物件來承擔。迪公尺特法則：只和身邊的朋友交流。

規則5：不要使用縮寫

我們總會在不自覺地在類名，方法名或者變數名中使用縮寫。縮寫會令人迷惑，也容易隱藏一些嚴重的問題。盡量保持類名和方法名稱中只包含一到兩個單詞。

規則6：保持實體物件簡單清晰

每個類的長度都不能超過50

行，每個包所包含的檔案不超過

10個。隨著類變得越來越小，職責越來越少，加之包的大小也受限制，因此包中的淚越來越集中，它們能協調完成乙個共同的目標。包和類一樣，也應該是內聚的。

規則7：如何類中的例項變數都不要超過兩個

大多數的類應該只負責處理單一的狀態變數，有時也可以擁有兩個狀態變數。每當為類新增乙個例項變數，就會立即降低類的內聚性。

規則8：使用一流的集合

規則9：不使用任何

getter/setter/property

這條規則通常被描述為：「講述而不要詢問（tell, don't ask

）」。

總結：能夠幫助程式設計師獲得物件導向程式設計的聖杯-------

資料封裝。不要使用

else,

盡量簡化條件判斷邏輯，鼓勵程式設計師適當使用多型。命名策略，鼓勵程式設計師使用一致的，直接的命名標準，不要使用難以理解的縮寫。

總之：就是想盡辦法消除**中的重複。我們每天都要面對複雜的問題，而我們的目標是：用簡練的**表達出簡單而優美的抽象。

個人感覺：這些規則太不可思議了，完全打破了我們平時的思維程式設計習慣嗎。給我的第一反應就是：我們能完全按照這些規則來做嗎？在日常的軟體開發中可行嗎？能夠完整遵守這些規則嗎？可是作者最後說了這麼一句：我們剛剛完成了乙個超過100 000

行**的系統，它嚴格遵守本文中提到的所有規則。參與這個專案的程式設計師全部都認真地遵守了上述規則。最終每個人都非常高興地看到：如果努力地擁抱簡單，那麼開發過程會快樂得多。

擁抱簡單，快樂程式設計，享受程式設計。