在寫程式的過程中，我們很容易聽到一句話：
「這個 Class 好像有點大。」
但問題往往不是「大不大」，
而是 你在修改它的時候，會不會開始緊張。
單一職責原則（SRP）之所以存在，
不是為了讓程式碼「看起來乾淨」，
而是為了在修改時，降低那種不知道會影響到哪裡的不確定感。
一個直覺上的例子
想像你按下一個按鈕，
原本只預期會發生一件事，
結果卻同時影響了好幾個你沒打算動的地方。
在生活中，這會讓人不太安心；
在程式裡，也是同樣的感覺。
很多時候，問題不在於功能多，
而在於 「這些功能為什麼會綁在一起？」
單一職責在關心什麼？
與其背定義，不如換一個比較好用的理解方式：
一段程式碼，應該只對一種「變動理由」，而不是任何事情改了都要動它。
也就是說，
你修改它，通常是因為某一類需求變了，
而不是任何小地方調整，都得碰到它。
當不同性質的變動被放在同一個地方，
未來每一次修改，風險就會被放大。
為什麼這件事對新手特別重要？
對經驗比較多的工程師來說，
他們往往能靠直覺避開危險的修改。
但對新手而言，
程式結構本身，就是安全網。
單一職責做得越清楚，
你就越容易知道「改這裡，影響範圍到哪裡為止」。
那「很大的 Class」一定有問題嗎？
不一定。
有些功能本來就高度相關，
它們幾乎總是一起被修改，
放在同一個地方反而更好理解。
單一職責不是在追求「小」，
而是在避免 不相關的東西被迫一起變動。
察覺
如果你真的遇到這種情況：
- 一個 Class 或 function 裡，塞滿了所有流程與細節
- 你每次改一小段，都要從頭到尾看一遍
- 心裡會擔心「會不會不小心影響其他地方」
那這通常不是你能力不足，
而是這段程式已經承擔了太多不同的責任。
這時候，才值得開始考慮拆分。
結語
單一職責不是規定你一定要怎麼寫，
而是在提醒你一件事：
當修改一個地方，不需要同時擔心其他無關邏輯時，程式通常會比較安全，也比較好維護。
覺察到這一件事情。
