單一職責原則
名詞解釋：
單一職責原則（srp：single responsibility principle）又稱單一功能原則，物件導向六個基本原則之一。它規定乙個類應該只有乙個發生變化的原因。該原則由羅伯特·c·馬丁（robert c. martin）於《敏捷軟體開發：原則、模式和實踐》一書中給出的。馬丁表示此原則是基於湯姆·狄馬克(tom demarco)和meilir page-jones的著作中的內聚性原則發展出的。
所謂職責是指類變化的原因。如果乙個類有多於乙個的動機被改變，那麼這個類就具有多於乙個的職責。而單一職責原則就是指乙個類或者模組應該有且只有乙個改變的原因。
一句話總結：
乙個類只負責乙個任務，就像乙個人在公司內只做一件事。
現實場景：
在乙個餐廳中假如有廚師、收銀員、後勤三種角色，每個角色都有不同的職責，廚師負責燒菜，收銀員負責結帳，後勤負責清洗工作。那麼他們的任務應該是分得很清楚的，只要是燒菜類的就交由廚師，收銀類的就找收銀員，後勤就只管洗碗。
**實現
/***廚師類
*/class cookperson
}/**
*收銀員類
*/class cashierperson
}/**
*後勤類
*/class washperson
}總結：
單一職責原則很簡單，但事務往往是兩面性的，粗看簡單確未必是簡單，簡單其實就是複雜。「簡單就是終極的複雜」，那麼複雜是終極的簡單嗎？一定不是！但也未必沒有是的可能。在以上**實現中實現了單一職責。假如有乙個新任務需要洗菜，我們只需要更改後勤類增加洗菜的功能，對別的類沒有影響。在設計軟體時也會自覺的遵守這一重要原則，因為這是常識。在軟體程式設計中，誰也不希望因為修改了乙個功能導致其他的功能發生故障。而避免出現這一問題的方法便是遵循單一職責原則。雖然單一職責原則如此簡單，並且被認為是常識，但是即便是經驗豐富的程式設計師寫出的程式，也會有違背這一原則的**存在。為什麼會出現這種現象呢？因為有職責擴散。所謂職責擴散，就是因為某種原因，職責被分化為粒度更細的職責task1和task2。 假如我們此時需增乙個配菜的任務，這個任務是由哪個類來完成呢，是由後勤類呢還是廚師類呢。又或者需求變更了我們不燒菜了，改為做蛋糕了等等。類的功能性就會引起變更，此時我們是考慮重用原類呢還是重新構建或者是擴散呢，因為這些都有不確定性，此時的簡單就不好把握了。所以說軟體的重構真是無處不在無時不有，那只有到具體情況具體分析了。
遵循單一職責原的優點有：
1.可以降低類的複雜度，乙個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；
2.提高類的可讀性，提高系統的可維護性；
3.變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改乙個功能時，可以顯著降低對其他功能的影響。
4.需要說明的一點是單一職責原則不只是物件導向程式設計思想所特有的，只要是模組化的程式設計，都適用單一職責原則。
單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...
單一職責原則
單一職責原則 乙個類，只有乙個引起它變化的原因。應該只有乙個職責。每乙個職責都是變化的乙個軸線，如果乙個類有乙個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當乙個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一起，會影響復用性。例如 要實現邏輯和介面的分離。對於user類，裡...
單一職責原則
問題由來 一心二用，效率降低 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 專注做某件事情 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t2完成職責p2功能。這樣，當修改類t1...