設計原則入門：單一職責原則 Single Responsibility Principle

在寫程式的過程中，你是否遇過一個類別或模組負責了太多事情，結果導致程式變得難以維護？這類情況經常被稱為「巨石類別 (God Class)」。當我們對這樣的類別做出任何變更時，改動可能會牽一髮動全身影響其他部分，這時候「單一職責原則 (SRP)」便派上用場。 單一職責原則是什麼？ 簡單來說，單一職責原則強調「每個類別或模組應該只負責一件事」。也就是說如果一個類別需要改變的原因超過一個，那麼它就違反了這個原則。 打個比方，就像一個專業廚師應該專心煮飯，而不應該一邊煮飯一邊修理水管，因為這樣可能兩件事都做不好。同樣道理，軟體設計中我們也應該讓每個類別只專注於它的核心功能，避免讓它肩負太多不同的責任，這樣不僅能讓程式碼變得更具彈性，也更容易維護。 舉個簡單的例子 假設有一個類別負責產生報告，同時還負責把報告儲存到檔案中，這就等於一個類別在做兩件事，違反了單一職責原則。當你需要修改報告的產生邏輯時，可能會影響到儲存的功能，反之亦然，這讓程式碼變得脆弱。 更好的設計方式是，將產生報告和儲存報告的責任分成兩個類別，這樣如果某一天你只需要修改報告的儲存方式，就不會碰到產生報告的部分，讓系統更加穩定。 為什麼這麼做？ 遵守單一職責原則的最大好處是「降低程式碼的耦合度」，也就是說，當每個類別只專注於一個職責時，變更一個部分不會影響到不相關的功能。另外，它還能讓系統更具可測試性，因為你只需要針對單一功能進行測試，而不必擔心其他部分的問題。 小心過度設計 雖然這個原則聽起來很好，但也不能過度拆分。如果每個類別都被切得太細，反而會讓程式碼變得複雜。因此在應用單一職責原則時，要根據實際情況找到適當的平衡。