有人能給我一個單一責任原則的例子嗎?我試圖理解它在實踐中是什麼意思,因爲我擔心我可能每天都會違反這個規則,因此一個班級有單一的責任。什麼是單一責任原則的例子?
回答
除非您要求更具體的內容,否則很難提供更多幫助。
單一職責是一類做一個具體的東西(的責任),而不是試圖做更多比它應該,它也被稱爲高內聚的概念。
班經常不開出低凝聚力,但通常經過幾個不同的版本,不同的開發人員加入到他們身上,突然間,你會發現,它成爲一個怪物或神級的一些調用它。所以這個類應該被重構。
它很難想出一個很好的例子,但我最近可以想到的是我們有一個類來管理不同的數據包處理階段,一種類型爲Chain of Responsibility
。這個類的最初意圖是維護一個階段列表並在它們上協調調用packetProcess()。那麼最後呢,每個人都會在處理階段添加任何東西(因爲經理類是訪問階段的一個簡單場所),尤其是階段配置。經理類不再有單一責任,而是負責調用配置更改的階段:因此凝聚力已經降低。
我們最終不得不重構管理器類,剝開所有階段的配置,並把它在一個工廠,因此可以使管理者做什麼它打算這樣做。
你有沒有工作中的例子 - 一個真實世界的例子。 –
幾周前我遇到了這個問題。我需要一個Object Factory類來創建不同類型的對象的實例,對它們進行序列化,將它們保存到數據庫等。我首先想到的是用Serialize方法創建一個Factory類,但是當我讀到SRP時,更有意義的是擁有一個專門用於Serialize的類,一個類用於DB中的Persist對象等等。這使得您的應用程序更易於維護和模塊化。 –
@SachinKainth,我在我的答案中添加了一個例子。 – Brady
破解應用程序的最有效方法是創建GOD類。這是跟蹤大量信息並承擔多項責任的類。一次代碼更改很可能會影響該類的其他部分,因此間接影響所有其他使用它的類。這反過來導致更大的維護混亂,因爲除了增加新功能之外,沒有人敢做任何改變。
下面的例子是定義一個人打字稿類,這個類不應該包括電子郵件驗證,因爲這不是一個人的行爲有關:
class Person {
public name : string;
public surname : string;
public email : string;
constructor(name : string, surname : string, email : string){
this.surname = surname;
this.name = name;
if(this.validateEmail(email)) {
this.email = email;
}
else {
throw new Error("Invalid email!");
}
}
validateEmail(email : string) {
var re = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i;
return re.test(email);
}
greet() {
alert("Hi!");
}
}
我們可以通過刪除改善上述類從Person類電子郵件驗證,並創建一個新的電子郵件類的責任,這將有責任:
class Email {
public email : string;
constructor(email : string){
if(this.validateEmail(email)) {
this.email = email;
}
else {
throw new Error("Invalid email!");
}
}
validateEmail(email : string) {
var re = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i;
return re.test(email);
}
}
class Person {
public name : string;
public surname : string;
public email : Email;
constructor(name : string, surname : string, email : Email){
this.email = email;
this.name = name;
this.surname = surname;
}
greet() {
alert("Hi!");
}
}
確保一個類只有一個respon可靠性使其在默認情況下也更容易看到它的作用以及如何擴展/改進它。
那麼現在我們會在我們的項目中獲得大量的單個methos課程? –
是的,您可以通過撰寫非常簡單的單一關注實體來創建更復雜的功能。 –
單一職責原則(SRP)指出,一類或方法只能做一件事情,不應該是有關的任何做任何事情。一個班級應該只有一個理由要改變。
一個典型的例子可以一EmailSender類:
- 這應該只是處理髮送電子郵件了。
- 這不應該負責從數據庫加載電子郵件內容,甚至格式化要發送的電子郵件內容。
Here是這方面的一篇文章。
一個班級應該只有一個理由要改變。
該原則規定,如果我們有兩個改變類的理由,我們必須將功能拆分爲兩個類。每個班級將只負責一個責任,如果將來我們需要做出一個改變,我們將在班級中處理它。
如果有兩個不同的原因需要更改,可以想象兩個不同的團隊可能出於兩個不同的原因在相同的代碼上工作。每個人都必須部署其解決方案,在編譯語言(如C++,C#或Java)的情況下,可能會導致與其他團隊或應用程序的其他部分不兼容的模塊。
該原理與耦合和內聚的概念密切相關。耦合是指應用程序的不同方面之間有着密不可分的聯繫,而內聚則指特定類或包的內容可能有多密切相關。單個類的所有內容都緊密耦合在一起,因爲類本身是[單個單元] [1],它必須完全使用或根本不使用。
我的博客文章在這:
http://javaexplorer03.blogspot.in/2016/12/single-responsibility-principle.html
https://www.youtube.com/watch?v=Gt0M_OHKhQE 此視頻支持「一個班級只能有一個改變原因」 – code90
- 1. PetClinic例子破單個責任原則
- 2. 單一責任原則 - 一個難以看到的例子?
- 3. 單一責任原則
- 4. 單一責任原則webapi
- 5. 什麼時候違反單一責任原則是合理的?
- 6. 單一責任原則是否違規
- 7. 您違反單一責任原則的最佳範例是什麼?
- 8. 是單一責任原則OOP的一個規則?
- 9. 幫助理解單一責任原則
- 10. 單一責任原則和課
- 11. 單一責任原則和知識庫
- 12. 單一責任原則 - 功能
- 13. 單一責任原則和Backbone.View
- 14. 我的代碼是否違反單一責任原則?
- 15. 這是單一責任原則的正確實施
- 16. 單一責任原則:改變原因的粒度
- 17. 按單責任原則重構方法
- 18. 退出($ status)是否違反單一責任原則?
- 19. 這個班是否遵循單一責任原則?
- 20. 單一責任原則是否適用於職能?
- 21. 嚴格遵守單一責任原則是否違反封裝?
- 22. 這個ruby模式是否遵守單一責任原則?
- 23. Android的單獨責任的例子
- 24. 在以下示例中對單責任原則感到困惑
- 25. 單一職責原則的實現
- 26. 代碼遵守單一責任原則和單元測試
- 27. 什麼是DLR層責任?
- 28. 單一責任原則(SRP)和我的服務類別
- 29. 單一責任原則與分離擔憂的區別
- 30. 瞭解SOLID設計的單一責任原則
看看這裏:http://stackoverflow.com/questions/659232/it-this-an-example-of-the-single-responsibility原則 –
http://www.phpfreaks.com/tutorial/oo-php-part-2-boring-oo-principles –
順便說一句,你沒有提到一個特定語言的例子,所以什麼都行:) –