1.3 我單純，所以我快樂

對于接口，我們在設計的時候一定要做到單一，但是對于實現類就需要多方面考慮了。生搬硬套單一職責原則會引起類的劇增，給維護帶來非常多的麻煩，而且過分細分類的職責也會人為地增加系統的復雜性。本來一個類可以實現的行為硬要拆成兩個類，然后再使用聚合或組合的方式耦合在一起，人為制造了系統的復雜性。所以原則是死的，人是活的，這句話很有道理。

單一職責原則很難在項目中得到體現，非常難，為什么？在國內，技術人員的地位和話語權都比較低，因此在項目中需要考慮環境，考慮工作量，考慮人員的技術水平，考慮硬件的資源情況，等等，最終妥協的結果是經常違背單一職責原則。而且，我們中華文明就有很多屬于混合型的產物，比如筷子，我們可以把筷子當做刀來使用，分割食物；還可以當叉使用，把食物從盤子中移動到口中。而在西方的文化中，刀就是刀，叉就是叉，你去吃西餐的時候這兩樣肯定都是有的，刀就是切割食物，叉就是固定食物或者移動食物，分工很明晰。這種文化的差異很難一步改造過來，但是我相信隨著技術的深入，單一職責原則必然會深入到項目的設計中，而且這個原則是那么的簡單，簡單得不需要我們更加深入地思考，單從字面上大家都應該知道是什么意思，單一職責嘛！

單一職責適用于接口、類，同時也適用于方法，什么意思呢？一個方法盡可能做一件事情，比如一個方法修改用戶密碼，不要把這個方法放到“修改用戶信息”方法中，這個方法的顆粒度很粗，比如圖1-7中所示的方法。

圖1-7 一個方法承擔多個職責

在IUserManager中定義了一個方法changeUser，根據傳遞的類型不同，把可變長度參數changeOptions修改到userBO這個對象上，并調用持久層的方法保存到數據庫中。在我的項目組中，如果有人寫了這樣一個方法，我不管他寫了多少程序，花了多少工夫，一律重寫！原因很簡單：方法職責不清晰，不單一，不要讓別人猜測這個方法可能是用來處理什么邏輯的。比較好的設計如圖1-8所示。

通過上面的類圖，如果要修改用戶名稱，就調用changeUserName方法；要修改家庭地址，就調用changeHomeAddress方法；要修改單位電話，就調用changeOfficeTel方法。每個方法的職責非常清晰明確，不僅開發簡單，而且日后的維護也非常容易，大家可以逐漸養成這樣的習慣。

所以，如果對接口、類、方法使用了單一職責原則，那么快樂的就不僅僅是你了，還有你的項目組成員，大家可以輕松而又愉快地進行開發；還有你的老板，減少了因為變更引起的工作量，減少了無謂的人員和資金消耗。當然，最快樂的也許就是你了，因為加官進爵可能等著你喲！

圖1-8 一個方法承擔一個職責