●定義
就乙個類而言，應該僅有乙個引起它變化的原因。
變化是指具體類的改變，如乙個moden類具有連線管理和資料通訊的功能，那麼這個類就有連線管理和資料通訊這兩個變化方向，此時就違背了「單一職責的原則」。
●關於「單一職責」
「單一職責」也就是「單一變化原因」。「職責」也就是引起類變化的原因。
「單一職責原則」是物件導向設計的第乙個基本原則，它可能是最簡單的也可能是最難運用的乙個原則！
通常，乙個類的「職責」越多，導致其變化的因素也就越多。因為每個職責都可能是乙個變化的軸線。這與我們在設計類時所採用的方法有關係。一般情況下，我們在設計乙個類的時候會把與該類有關操作都組合到這個類中，這樣做的後果就有可能將多個職責「耦合」到了一塊，當這個類的某個職責發生變化時，很難避免類的其它部分不受影響，這最終導致程式的「脆弱」和「僵硬」。
解決這種問題的方法就是「分耦」，將不同的職責分別進行封裝，不要將其組合在乙個類中，使這個類只有乙個可能會引起它變化的原因。這樣做將會使你的程式易於修改和維護。但這個過程可能是很困難的，因為我們不總是能輕易知道那些職責會發生變化，那些職責應該被提取出來。所以，你的程式可能會有乙個演化的過程，從中得出這些會發生的職責並進行另外的封裝。需要注意的一點就是當實標情況中的職責確實發生了變化，應用該原則才是有意義的。如果乙個類組合了多個職責，但這些職責在實際情況中根本不會發生變化，那完全沒有必要提前費盡心機去應用這個原則。
總結：
srp好處：
消除耦合，減小因需求變化引起**僵化性臭味
注意點：
1.乙個合理的類，應該僅有乙個引起它變化的原因，即單一職責；
2.在沒有變化徵兆的情況下應用srp或其他原則是不明智的；
3.在需求實際發生變化時就應該應用srp等原則來重構**；
4.使用測試驅動開發會迫使我們在設計出現臭味之前分離不合理**；
4.如果測試不能迫使職責分離，僵化性和脆弱性的臭味會變得很強烈，那就應該用facade或proxy模式對**重構；
例項：
違反srp原則**:
modem介面明顯具有兩個職責：連線管理和資料通訊；
class modem
此時應該把的modem的兩個職責分到兩個類中
class datachannel
class connection
新的modem類：
class modem
//字段
private datachannel datachannel;
private connection con;
//操作
public void dial(string pno)
public void hangup()
.......
public void send(char c)
.......
public void recv()
.......
}
單一職責原則 SRP
一 srp簡介 srp single responsibility principle 就乙個類而言，應該只專注於做一件事和僅有乙個引起它變化的原因。所謂職責，我們可以理解他為功能，就是設計的這個類功能應該只有乙個，而不是兩個或更多。也可以理解為引用變化的原因，當你發現有兩個變化會要求我們修改這個類...
單一職責原則SRP
1 乙個類，只有乙個引起它變化的原因。應該只有乙個職責。每乙個職責都是變化的乙個軸線，如果乙個類有乙個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當乙個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一起，會影響復用性。例如 要實現邏輯和介面的分離。2 什麼是職責？srp中，把...
單一職責原則 SRP
單一職責原則 single responsibility principle srp 基本概念 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。優點 問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p...