1.4 最佳實踐 閱讀到這里，可能有人會問我，你寫的是類的設計原則嗎？你通篇都在說接口的單一職責，類的單一職責你都違背了呀！呵呵，這個還真是的，我的本意是想把這個原則講清楚，類的單一職責嘛，這個很簡單，但當我回頭寫的時候，發覺并不是這么回事，翻看了以前的一些設計和代碼，基本上拿得出手的類設計都是與單一職責相違背的。靜下心來回憶，發覺每一個類這樣設計都是有原因的。我查閱了Wikipedia、OODesign等幾個網站，專家和我也有類似的經驗，基本上類的單一職責都用了類似的一句話來說"This is sometimes hard to see"，這句話翻譯過來就是“這個有時候很難說”。是的，類的單一職責確實受非常多因素的制約，純理論地來講，這個原則是非常優秀的，但是現實有現實的難處，你必須去考慮項目工期、成本、人員技術水平、硬件情況、網絡情況甚至有時候還要考慮政府政策、壟斷協議等因素。比如，2004年我就做過一個項目，做加密處理的，甲方就甩過來一句話，你什么都不用管，調用這個API就可以了，不用考慮什么傳輸協議、異常處理、安全連接等。所以，我們就直接使用了JNI與加密廠商提供的API通信，什么單一職責原則，根本就不用考慮，因為對方不公布通信接口和異常判斷。 對于單一職責原則，我的建議是接口一定要做到單一職責，類的設計盡量做到只有一個原因引起變化。