文章出處
文章列表
一、SRP簡介（SRP--Single-Responsibility Principle）：
就一個類而言，應該只專注于做一件事和僅有一個引起它變化的原因。
所謂職責，我們可以理解他為功能，就是設計的這個類功能應該只有一個，而不是兩個或更多。也可以理解為引用變化的原因，當你發現有兩個變化會要求我們修改這個類，那么你就要考慮撤分這個類了。因為職責是變化的一個軸線，當需求變化時，該變化會反映類的職責的變化。
“就像一個人身兼數職，而這些事情相互關聯不大，，甚至有沖突，那他就無法很好的解決這些職責，應該分到不同的人身上去做才對。”
二、舉例說明：
違反SRP原則代碼:
modem接口明顯具有兩個職責：連接管理和數據通訊；
modem接口明顯具有兩個職責：連接管理和數據通訊；
interface Modem
{
public void dial(string pno);
public void hangup();
public void send(char c);
public void recv();
}
{
public void dial(string pno);
public void hangup();
public void send(char c);
public void recv();
}
如果應用程序變化影響連接函數，那么就需要重構：
interface DataChannel
{
public void send(char c);
public void recv();
}
interface Connection
{
public void dial(string pno);
public void hangup();
}
{
public void send(char c);
public void recv();
}
interface Connection
{
public void dial(string pno);
public void hangup();
}
三、SRP優點：
消除耦合，減小因需求變化引起代碼僵化性臭味
四、使用SRP注意點：
1、一個合理的類，應該僅有一個引起它變化的原因，即單一職責；
2、在沒有變化征兆的情況下應用SRP或其他原則是不明智的；
3、在需求實際發生變化時就應該應用SRP等原則來重構代碼；
4、使用測試驅動開發會迫使我們在設計出現臭味之前分離不合理代碼；
5、如果測試不能迫使職責分離，僵化性和脆弱性的臭味會變得很強烈，那就應該用Facade或Proxy模式對代碼重構；
2、在沒有變化征兆的情況下應用SRP或其他原則是不明智的；
3、在需求實際發生變化時就應該應用SRP等原則來重構代碼；
4、使用測試驅動開發會迫使我們在設計出現臭味之前分離不合理代碼；
5、如果測試不能迫使職責分離，僵化性和脆弱性的臭味會變得很強烈，那就應該用Facade或Proxy模式對代碼重構；
文章列表
全站熱搜
留言列表
