最近前輩推薦我讀《設計模式之禪》這本書，原因是我寫的代碼質量實在是一言難盡，開發速度很快，但是bug數就很多了，設計原則這種知識就需要掌握 寫這篇文主要是記錄自己的學習以及督促自己 第一章【單一職責】 從我理解的層面來談談單一原則：明確每個類每個方法的任務，只做一件事，不能一法兩用 這也是我最大的一 ...
最近前輩推薦我讀《設計模式之禪》這本書，原因是我寫的代碼質量實在是一言難盡，開發速度很快，但是bug數就很多了，設計原則這種知識就需要掌握
寫這篇文主要是記錄自己的學習以及督促自己
第一章【單一職責】
從我理解的層面來談談單一原則：明確每個類每個方法的任務，只做一件事，不能一法兩用
這也是我最大的一點感受
尤其是在看這張圖的時候，如果是我的話，我肯定會寫在一起，不可能分的這麼細，所以單一職責的難點就是：很難劃分職責
其次他的好處：
● 類的複雜性降低，實現什麼職責都有清晰明確的定義；
● 可讀性提高，複雜性降低
● 變更引起的風險降低
我認為不好的點：
維護性並不是特別高吧，當業務很複雜的情況下，這種拆分，會變得很冗餘，物極必反可能是這個道理
實際應用：
"我的建議是介面一定要做到單一職責，類的設計儘量做到只有一個原因引起變化"這是作者原話，看完後我就記得我寫過的一段代碼，通過傳type跳轉不同業務邏輯的方案，看完後我就會把單一原則和封裝結合在一起去想，什麼是可以進行封裝的？業務邏輯的復用嗎?那也算是完成很多不同的事，這樣封裝又不滿足單一職責了，不知道評論區的大佬能不能幫我解答一下，非常感謝！！！！
