#分享 A Solid Guide to SOLID Principles

最近因為工作的關係，所以認真的來學一下 refactor（其實是自己的 code 寫太爛才不得不學的XD）直接給懶人包：這篇是我查到範例最清楚的教學文五個例子跟你說怎麼實踐 SOLID 的精神，看完大概就知道怎麼 refactor 自己的 code了 Reference -

那就直接介紹第一個精神 S - Single Responsibility ------------------------------------------------------------------------------------------------------------------------ 所謂的 Single Responsibility 意思就是每個 class 都只做一件事情掃地阿姨就只負責掃地，要擦窗戶的話要再寫一個擦窗戶阿姨的 class 這樣做有幾個好處： 1. Testing：符合 Single Responsibility 的 class 比較好寫 test case 2. 低耦合：因為他的 dependency 會比較少 3. Organization：Smaller, well-organized classes are easier to search than monolithic ones 文中給了一個例子：假設你有個 Book 的 class，有一些 replace 的 function

之後你有印出來的需求的時候呢以前的你可能會想要直接寫在 Book 的 class 上面

但這樣就違反 Single Responsibility 了所以建議這樣做：

O - Open for Extension, Closed for Modification ------------------------------------------------------------------------------------------------------------------------ 一言以蔽之就是 classes should be open for extension, but closed for modification. In doing so, we stop ourselves from modifying existing code and causing potential new bugs 屍體寫不少的人應該都有這種經驗到後期會很排斥改 code，比較喜歡寫新專案看完這句話我才知道因為我過去都違反這個準則所以常常把既有的功能改壞，導致每次要改 code 都會有很大的心理負擔好在作者給出解法如果你有個 Guitar 的 class

後來嫌吉他素色不夠潮，想要通吉他千萬不要直接改在吉他的 class 上再寫一個新的吉他 subclass 去繼承，可以確保你不會搞砸舊的功能

L - Liskov Substitution ------------------------------------------------------------------------------------------------------------------------ 這個我大學上「物件導向」的時候好像就有學過不過那個時候完全沒有 refactor 的概念就是 🤣 如果你的 function 可以接受 Guitar 的話，那我用 SuperCoolGuitarWithFlames 去替換掉也要沒事 I - Interface Segregation ------------------------------------------------------------------------------------------------------------------------ ZooEmployee 這個 Class，請分成 ZooFeeder, ZooCleaner, ZooXXXStaff 等等細小的 class 而不是就設計一個 ZooEmployee 這個職責包山包海的 class，這是慣老闆才做的事XD D - Dependency Inversion ------------------------------------------------------------------------------------------------------------------------ 這是我這次 refactor 最常用的技巧 The principle of Dependency Inversion refers to the decoupling of software modules. This way, instead of high-level modules depending on low-level modules, both will depend on abstractions. 如果你今天要實作一個 Windows98 的 class 請不要直接把 keyboard 和 monitor 直接寫死在裡面

而是設計 Keyboard 的 interface 然後再把 instance 傳進來

這樣之後你想要實作機械鍵盤之類的東東時 Windows98 的接口就不用改，因為這些 interface 都是繼承 Keyboard 的 interface 都有一樣的 API 可以調用，這樣就叫做 dependency injection 類並不知道你傳啥 instance 進來，我只知道你們都有實作某個 interface 所以我認 interface 不認人，一律呼叫 interface 的 API 就對了大概是這樣最後介紹一下我現在的應用場景 ------------------------------------------------------------------------------------------------------------------------ 這是微博推薦算法的架構圖看起來就是個很可怕的龐然大物我照著實作就不知不覺就把 2000 行擠在同一份檔案了😱 所以才會有這篇想要學怎麼 refactor

不過看架構圖的分類就知道，每層都可以設計一個 interface 然後再實作多個 instance 去繼承他這樣就簡單多了現在文章打完我也剛好 refactor 完拉但是我沒有寫 unit tests 怎麼知道我 refactor 沒有搞砸呢？好問題，但我已經 deploy 了呢ㄎㄎㄎ管他的 ------------------------------------------------------------------------------------------------------------------------ 如果你喜歡這篇文章，請按一下喜歡以及右上角訂閱按鈕。看更多文章：