設計模式-單一職責原則

    單一職責原則是指讓一段代碼的功能最細化並單一化，就是讓它只專一於幹一件事。主要是爲了實現解耦，並讓代碼的維護性和可讀性更強。

    解耦是在程序設計中最重要的一個黃金法則，單一職責原則也是爲了實現解耦的一種設計思想。若是一個單位內的代碼所承擔的職責的種類過多，那麼當其中一個職責在未來發生變化的時候，頗有可能會對其餘職責的邏輯產生影響。而且這樣的一段代碼，可讀性和維護性都很糟糕。因此經過單一職責原則，把代碼的邏輯進一步的拆分到不一樣的地方去，讓每段的代碼都只專一於某一個職責，這樣在之後維護起來，也好快速定位。

    我通過的幾個項目中，都看到過把各類邏輯功能都塞到了一個實現類裏面去。像是請求參數校驗、異常處理、各類業務邏輯的檢查、構造響應實體等等，這些或是存在同一個類，或是散佈在各個方法裏。相信你也看到過一個大類或是大方法。每次修改的時候都當心翼翼，生怕坑了別的地方。能夠看到諸如此類的功能並不是核心的業務功能，而他們之間互相都沒有什麼關聯，這時候最佳的實踐方式是把他們都相互拆離出去。參數校驗的就只幹參數校驗，處理異常的就只處理異常。

    怎麼分離，分離到哪裏去倒並無一個明確的答案。就拿參數校驗來講，不少接口都須要，而不一樣的接口的校驗規則是不一樣的。好比新增和修改用到了同一個參數bean，而修改的id必需的，新增的id是必不需的（注意和非必需的區別），而新增的一些參數是必需的，而修改則是非必需。如下是幾個常見思路：

• 放到一個只作參數校驗的工具類裏，每一個方法負責不一樣的校驗
• 業務service類繼承一個BaseService類，在BaseService裏寫一個校驗的方法。至於一個方法怎麼應對不一樣的校驗策略，這個能夠用以前說到的工廠模式或策略模式實現，又或是經過方法的參數動態實現校驗的動態
• 集成第三方庫。好比參數校驗能夠用到支持Bean Validation（JSR-303）的hibernate validator

    須要注意的是也不能過分分離，就像不能過分設計同樣。我認爲當一個代碼單位裏出現了不少互不相干的邏輯代碼是屬於不正常的。我之因此說代碼單位是由於從system->module->service->class->method這樣的層次下來，站在不一樣的層次描述的意義是有不一樣的。不可避免的有一些邏輯互相有關聯，那最好仍是不要拆分了，放在一塊兒代碼反而更流暢。所幸這樣的狀況不多。

    不必強迫症似的必定要拆分的精細到單個單個的功能塊，或者是一個方法不能多少行之類的。