單一職責原則（Single Responsibility Principle, SRP）
當你跟同事爭論的時候冒出一句，你這個設計不符合SRP原則時，那是多麼的裝比，說不定被你的氣勢直接壓住了，哈哈，開個玩笑，實力纔是說話權。
單一職責的定義：應該有且僅有一個原因引起類的變更。原話是： There should never be more than one reason for a class to change.。簡單的像句廢話，但是確實很難做到。舉個例子：打電話，電話通話過程有四個：撥號，通話，迴應，掛機，那我們寫個接口，go語言如下：
type IPhone interface{
dial(phoneNumber string)
chat(p person)
hangup()
}
實現類你們就自己寫吧，這個接口大家看着有沒有問題，可能大家覺得沒啥問題，當然我可能有時候也會覺得OK。單一職責原則要求一個接口或類只有一個原因引起變化，，也就是說一個接口或者類只需要一個職責，他就負責一件事情，這時候你看看上面接口是否做到了，好像不是吧。
電話這個接口可不止一個職責，她包含兩個職責：協議管理和數據傳送，dial()和hangup()兩個方法是協議管理，chat()是數據傳送，然後我們想想協議變化會影響類的變化嗎？會的，所以我們應該把這兩個職責分別寫兩個接口，這樣他們就不互相影響了。其實，對於協議管理和數據傳輸兩個職責，你還可以往下細分，這樣每個小工能都會有一個接口，但是，並不建議這麼做，因爲這會帶來設計的複雜性。所以在使用單一職責原則時應該把我一個度。這個主要看工程人員的把控，比不一定完全做到，但你得有這個意識。
單一職責的好處：
（1）類的複雜性降低，實現什麼職責都有清晰明確的定義
（2）可讀性提高，複雜性降低了
（3）可維護性高，可讀性高了，自然可維護性就高了
（4）變更引起的風險降低，如果接口的單一職責做得好，一個接口修改只對相應的實現類有影響，對其他的接口無影響，這對系統的擴展性，維護性都有非常大的幫助。
其實單一職責原則最難分的就是職責，所以建議接口一定要做到單一職責，類的設計儘量做到只有一個原因引起變化。這可能會帶來一定的工作量，但是是值得的。當然，工程師在平時設計中，可能會考慮到工作量的問題，難免會有妥協，但是爲了以後的便利，還是值得的。