我在差不多半年前讀過這樣一本書，《Head First 設計模式》，當時就被設計模式這四個字吸引了，曾經一度讓我有了初戀般的感覺。但是沒想着，做點記錄，現在挺後悔的，所以差不多把設計思想又還給作者。這次重拾設計模式，就要開始做記錄啦，寫的不好的地方，多多包涵。獻上一句我做喜歡的話，“三十年河東，三十年河西，莫欺少年窮”。
在六大設計原則裏面，單一職責原則是最引人們爭議的，下面我們就圍繞這幾個問題來進行記錄。
- 單一職責原則的官方定義是什麼？
- 爲什麼會引起人們的爭議？
- 在現實開發中，我們採取的折中措施是什麼？
- 單一職責原則的好處是什麼？
先來解決第一個問題,單一職責原則的定義是什麼？
單一職責原則的定義是：應該有且僅有一個原因引起類的變更。
那爲什麼會引起人們的爭議呢？
單一職責原則規定，一個職責一個接口，但是職責並沒有一個量化的標準。下面來看一個例子。
T先生要寫一個電話的類，他思考着，呀，我剛學了單一職責原則，就一個職責嘛！於是他寫了這樣一個類。
public interface Iphone {
//撥通電話
public void dial(String phoneNumber);
//通話
public void chat(Object o);
//通話完畢
public void hangup();
}只是T先生寫的電話的類圖：
正在這時，Z先生剛好路過，看到信心滿滿的T先生，說，“你這不對啊，這個接口裏面是單一原則嗎？這裏面好像包含這兩個職責吧，你看看是不是我說的這樣，這個接口包含了，電話接通與通話的信號的轉化（這裏我們可以理解爲我們可以用移動，也可以用電信呀）”，所以類圖應該是這樣畫的。
這時孟先生剛好過來，孟先生是公司的CTO嘛，看手下的小夥伴談論的這麼熱烈，也加入了討論。Z先生啊，你的想法是完全正確的，接口和類都實現了單一原則，但是，注意但是！！！你這樣子給我們的項目增加了很多的實現單一接口的類，還有Phone裏面出現了組合，這極大地增強了代碼的耦合性。T先生呢，你這樣子的設計也沒有大的問題，在項目工期如果緊急的話，我還是建議你這樣做，那下面我折中來給你們畫一個類圖吧。
孟先生畫完圖，就瀟灑地走了。
總結，一個職責對應一個接口，接口一定要做到單一職責，類的設計儘量做到單一職責。同樣方法也要遵循單一原則，即一個方法執行一項功能。