A class should have only one reason to change.
一個類別或方法，只會有一個修改的理由

當如果程式碼有過多職責時，就跟瑞士刀一樣，提供五花八門的功能，複雜又難以維護

(圖片來源 : https://partsolutions.com/engineering-the-worlds-largest-swiss-army-knife-the-1300-wenger-giant/)

所以，由於程式碼職責定義的越明確、程式碼會越簡潔，添加功能時你會知道要去哪邊添加，出問題時，也可以更明確的知道該去哪邊處理。相對提高了穩定性(健壯性)、可讀性與可維護性。

例如，在公司裡面 :
薪水有問題，你會直接去找會計
設計有問題，你會去找設計師
程式有問題，你會去找 PM 工程師
這是因為你知道他們相對應的職責

單一職責原則我覺得很像公司管理情況 :

公司人少的時候，工作拆分可能不需要很明確，甚至可能一人兼多職 :

假設公司初期便打算成立比較大的公司時，初期考慮的東西就會變多

當公司規模變的更大，原本的規劃已經不符現況，此時可能會重新規劃

單一職責原則最麻煩的，就是並沒有一定的標準，所以職責的拆分取決於開發者的情境與經驗

• 當功能很單純時，即便沒有特別拆權責，也不會難以維護。
• 而預計功能有一定規模時，通常你便會預先做好規劃。
• 當功能超出你的規劃時，類別已經過於複雜，表示類別可以拆出其他職責。

感謝收看，下次見 :)..