1.2 絕殺技，打破你的傳統思維 解釋到這里，估計你已經很不屑了，“切！這么簡單的東西還要講？！”好，我們來講點復雜的。SRP的原話解釋是： There should never be more than one reason for a class to change. 這句話初中生都能看懂，不多說，但是看懂是一碼事，實施就是另外一碼事了。上面講的例子很好理解，在實際項目中大家都已經這么做了，那我們再來看看下面這個例子是否好理解。電話這玩意，是現代人都離不了，電話通話的時候有4個過程發生：撥號、通話、回應、掛機，那我們寫一個接口，其類圖如圖1-4所示。  圖1-4 電話類圖 我不是有意要冒犯IPhone的，同名純屬巧合，我們來看一個這個過程的代碼，如代碼清單1-2所示。 代碼清單1-2 電話過程 public?interface?IPhone?{ ?????//撥通電話 ?????public?void?dial(String?phoneNumber); ?????//通話 ?????public?void?chat(Object?o); ?????//通話完畢，掛電話 ?????public?void?hangup(); } 實現類也比較簡單，我就不再寫了，大家看看這個接口有沒有問題？我相信大部分的讀者都會說這個沒有問題呀，以前我就是這么做的呀，某某書上也是這么寫的呀，還有什么什么的源碼也是這么寫的！是的，這個接口接近于完美，看清楚了，是“接近”！單一職責原則要求一個接口或類只有一個原因引起變化，也就是一個接口或類只有一個職責，它就負責一件事情，看看上面的接口只負責一件事情嗎？是只有一個原因引起變化嗎？好像不是！ IPhone這個接口可不是只有一個職責，它包含了兩個職責：一個是協議管理，一個是數據傳送。dial()和hangup()兩個方法實現的是協議管理，分別負責撥號接通和掛機；chat()實現的是數據的傳送，把我們說的話轉換成模擬信號或數字信號傳遞到對方，然后再把對方傳遞過來的信號還原成我們聽得懂的語言。我們可以這樣考慮這個問題，協議接通的變化會引起這個接口或實現類的變化嗎？會的！那數據傳送（想想看，電話不僅僅可以通話，還可以上網）的變化會引起這個接口或實現類的變化嗎？會的！那就很簡單了，這里有兩個原因都引起了類的變化。這兩個職責會相互影響嗎？電話撥號，我只要能接通就成，甭管是電信的還是網通的協議；電話連接后還關心傳遞的是什么數據嗎？通過這樣的分析，我們發現類圖上的IPhone接口包含了兩個職責，而且這兩個職責的變化不相互影響，那就考慮拆分成兩個接口，其類圖如圖1-5所示。  圖1-5 職責分明的電話類圖  圖1-6 簡潔清晰、職責分明的電話類圖 這個類圖看上去有點復雜了，完全滿足了單一職責原則的要求，每個接口職責分明，結構清晰，但是我相信你在設計的時候肯定不會采用這種方式，一個手機類要把ConnectionManager和DataTransfer組合在一塊才能使用。組合是一種強耦合關系，你和我都有共同的生命期，這樣的強耦合關系還不如使用接口實現的方式呢，而且還增加了類的復雜性，多了兩個類。經過這樣的思考后，我們再修改一下類圖，如圖1-6所示。 這樣的設計才是完美的，一個類實現了兩個接口，把兩個職責融合在一個類中。你會覺得這個Phone有兩個原因引起變化了呀，是的，但是別忘記了我們是面向接口編程，我們對外公布的是接口而不是實現類。而且，如果真要實現類的單一職責，這個就必須使用上面的組合模式了，這會引起類間耦合過重、類的數量增加等問題，人為地增加了設計的復雜性。 通過上面的例子，我們來總結一下單一職責原則有什么好處： ● 類的復雜性降低，實現什么職責都有清晰明確的定義； ● 可讀性提高，復雜性降低，那當然可讀性提高了； ● 可維護性提高，可讀性提高，那當然更容易維護了； ● 變更引起的風險降低，變更是必不可少的，如果接口的單一職責做得好，一個接口修改只對相應的實現類有影響，對其他的接口無影響，這對系統的擴展性、維護性都有非常大的幫助。 看過電話這個例子后，是不是想反思一下了，我以前的設計是不是有點問題了？不，不是的，不要懷疑自己的技術能力，單一職責原則最難劃分的就是職責。一個職責一個接口，但問題是“職責”沒有一個量化的標準，一個類到底要負責那些職責？這些職責該怎么細化？細化后是否都要有一個接口或類？這些都需要從實際的項目去考慮，從功能上來說，定義一個IPhone接口也沒有錯，實現了電話的功能，而且設計還很簡單，僅僅一個接口一個實現類，實際的項目我想大家都會這么設計。項目要考慮可變因素和不可變因素，以及相關的收益成本比率，因此設計一個IPhone接口也可能是沒有錯的。但是，如果純從“學究”理論上分析就有問題了，有兩個可以變化的原因放到了一個接口中，這就為以后的變化帶來了風險。如果以后模擬電話升級到數字電話，我們提供的接口IPhone是不是要修改了？接口修改對其他的Invoker類是不是有很大影響？ 注意　單一職責原則提出了一個編寫程序的標準，用“職責”或“變化原因”來衡量接口或類設計得是否優良，但是“職責”和“變化原因”都是不可度量的，因項目而異，因環境而異。