今天要介紹的是SRP（Single Responsibility Principle）單一責任原則！
一般我們在寫程式時最怕的不是寫不出來，而是「改程式找不到地方改」。或者，不管什麼問題都是改同一支class（也就是那支class非常的肥大）。

這就跟假設我們要到市政府辦事情時居然找不到承辦人一樣，或者什麼事都找同一個人（那個人應該會累灘了吧）一樣，都不是很好的歸納方式。根據書上對於SRP的定義是：

『你只有一個理由需要更改這個class，如果有一個以上的理由就表示：這個class負責超過一個以上的責任。』

在這個社會上，每個人都各司其職。如果你牙齒痛，你不會去找獸醫；如果你想查旅遊資訊，你不會來問IT邦的論壇問。相對的軟體系統也是一樣，系統裡的每一個物件都應該具有單一的責任，所有的物件服務都應該聚焦在單一個責任上面。所以也有人稱SRP為內聚力。

那如果責任很大呢？那就分攤一下啊~有句話說的好:『如果要把昨天的重擔和明天的煩惱都在今天一起背上，再強的人也會倒下』。咦~好像扯太遠了！反正就是要做好分類責任歸屬啦！不要通通都攬在一起！

那要怎麼判斷到底這個責任屬不屬於這個class呢？其實沒有絕對的方法，還是要靠我們的經驗和常識去判斷。不過根據『深入淺出物件導向』這本書上有提供一個方法，雖然不是能百分之百適用所有的案例，但也是個不錯的方法：

這個方法就是：用 「類別名稱」 來做類別名稱裡面的 「方法名稱」

舉個例子來說, 看下面這個 class diagram，然後試著用這個規則唸念看：

可以使用「機車」來「加速」
可以使用「機車」來「減速」
可以使用「機車」來「檢查汽油存量」
可以使用「機車」來「加油」
可以使用「機車」來「開大燈」
可以使用「機車」來「洗車」

是不是覺得『可以使用「機車」來「加油」』和『可以使用「機車」來「洗車」
』這兩個很怪呢？沒做，「加油」及「洗車」不是機車內建的功能，所以就需要將這兩個Method移到其他的地方去。

可是說真的，這個還是需要靠一點經驗和常識才會比較容易區別。這樣說還是會有一點「籠統」。如果說是電視遙控器呢？是不是要把功能都放在電視遙控器這個類別上呢？
當然不要阿，如果是電視遙控器，這時候可以使用Facade這個設計模式來配合使用，一定會更好！

當然，我相信這些例子一定還是有人會看得很模糊，所以如果有更好的例子或方法，歡迎大家分享一下囉！

文章導覽
全系列
上一篇
下一篇