六大設計原則之單一設計原則

single responsibility principle（srp）：單一設計原則

它規定乙個類只有乙個發生變化的原因。如果多餘乙個導致類變更的原因，則違反了srp。

分別建立兩個類t1、t2，使t1完成職責p1功能，t2完成職責p2功能。這樣當修改t1時，不會使職責p2發生故障風險，同理當修改t2時，也不會使p1發生故障。

但是現實中，不管是新手，還是資深程式設計師，經常會違反，這不僅僅是技術的問題，還有職責擴散，就是因為某種原因，職責p被分化成粒度更細的職責p1和p2.

比如：類t只負責乙個職責p，這樣設計是符合單一職責原則的。後來由於業務變更，需要將p細化成粒度更細的職責p1、p2。這時如果要遵循單一職責原則，也需要將t細化成t1和t2，分別負責p1，p2兩個職責。如果程式已經完成了，這樣寫太浪費時間。所以簡單修改t，用它來負責兩個職責也是可行的。雖然這樣會違背單一職責原則。（這樣的風險在於職責擴散的不確定性，因為我們不會想到這個職責p，未來可能會擴散為p1,p2，p3。。。，所以記住，在職責擴散到我們無法的程度之前，立即對**進行重構）。

class
animal 
} public
class
client 
}

如上面**，每個動物都有呼吸空氣這個職責。但是現在加入新的動物魚。它不需要呼吸空氣，我們就改變將animal這個類細化成兩個類，terrestrial和aquatic

class
terrestrial 
} class
aquatic 
} public
class
client 
}

如果要遵循單一職責原則，還需要將client也細化成兩個類，這樣開銷太大，如果直接修改類animal，

class
animal
else
} } public
class
client 
}

雖然不符合單一職責原則，但是這樣工作量會減少很多。但是以後如果又出現淡水魚和海水魚，這樣又得修改animal的breathe()，而對原有**會呼叫陸地動物相關功能帶來風險，也許在有一天發現「牛呼吸水」，這種修改方式直接在**級別上違背了單一職責原則，雖然修改簡單，但是隱患是最大。

class
animal 
public
void
breathe2(string animal) 
} public
class
client 
}

可以看出，這種修改方式沒有修改原來的方法，只是在原來類中新增乙個方法，這樣雖然也違背了單一職責原則，但是在方法級別上卻是符合單一職責原則的，因為它並沒有動原來方法的**，。這三種方式各有優缺點。實際中，遵循的原則應該是：只有邏輯足夠簡單，才可以在**級別上違反單一職責原則，只有類中方法數量比較少，才可以在方法級別上違反單一職責原則。

遵循單一職責原則優點：

單一職責原則不只是物件導向程式設計思想所持有的，只要是模組化的程式設計，都使用單一職責原則。

注意：單一職責原則提出了乙個編寫了乙個編寫程式的標準，用「職責」和「變化原因」來衡量介面或類設計的是否優良，但是「職責」和「變化原因」是不可度量的，因專案而異，因環境而異。

單一職責原則很難在專案中得到體現。在實際中，會考慮技術人員的地位和話語權，考慮環境，考慮工作量，考慮人員技術水平，考慮硬體等等，最終妥協的是精彩違背單一設計原則（如果生搬硬套單一原則，那麼類的資料太多，維護困難），也許隨著技術的深入，單一原則會越來越體現在專案中。

**：參考：《設計模式之禪》

六大設計原則之單一設計原則

六大設計原則之單一職責原則

Java六大設計原則單一原則

六大設計原則單一職責原則

六大設計原則之單一設計原則

六大設計原則之單一職責原則

Java六大設計原則 單一原則

六大設計原則 單一職責原則

相關推薦

Java六大設計原則單一原則

六大設計原則單一職責原則