什麼是單一職責原則也就是說我們使類或介面變化，只能有乙個理由。但是在實際開發的過程中，我們很容易做到介面單一職責，很難做到類單一職責。定義：有且僅有乙個使介面或類產生變化的原因。
例如：我們以查詢資料，處理資料，返回資料為例。
如果我們這樣設計乙個介面：
public
inte***ce
iuserbo
public
class
userbo
那麼這就不符合單一職責原則了嗎。當然這裡所說的單一職責，也應該用於方法，
例如：某個方法就是用於查詢資料的，另外乙個方法就只用於處理得到的資料。
但是我們把這個介面設計成符合單一職責原則時：
public
inte***ce
userdao
public
inte***ce
userservice
public
inte***ce
usercontroller
處理dao層返回的資料，而controller層的職責就是與頁面互動。
當然有的人會反駁我，說controller層的職責是接收請求，和返回響應 ，這也就是我們在專案中有可能違背單一職責原則的原因有二：
1.如果完全遵循單一職責原則，那麼我們的系統類的複雜度會變高。
2.每個人對於職責劃分的理解不同，a可以把與資料庫互動認為是一種職責，但是b可以認為在與資料庫互動的過程中，查詢是一種職責，修改是另一種職責，新增又是一種職責…
當然，單一職責原則還是有優點的：
1.類的複雜性降低，實現什麼職責都有明確的定義所以對於單一職責原則，設計模式之禪的作者就建議了：在設計時，介面一定要做到單一職責原則，而類的設計盡量做到單一職責原則。2.可讀性提高
3.可維護性提高
4.變更引起的風險降低
設計原則之單一職責原則
無論是什麼設計原則，全部都是圍繞 專案的生命週期 和 高內聚，低耦合 這兩個關鍵字。定義 單一職責原則 srp single responsibility principle 又稱單一功能原則，它規定了乙個類應該只有乙個發生變化的原因，即乙個類只負責一項職責。字面上很好理解，但是如果做起來卻很難做到...
設計原則 單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...
設計原則 單一職責原則
1 原則的定義 2 原則設計的初衷 3 能解決哪些問題 4 有哪些場景可以使用 單一職責原則，英文名single responsibility principle,縮寫為srp。乙個類或者模組只負責完成乙個職責 或者功能 也就是說，不要設計大而全的類，要設計粒度小，功能單一的類。換個角度來講就是，乙...