單一職責原則

如果有一個用戶管理類,類圖如下

?

我想,任誰也能看的出這個接口設計的有問題,用戶的屬性和用戶的行為沒有分開,應該把用戶的信息抽取成一個業務對象,把用戶的行為抽取成一個業務對象,按照這個思路對類圖進行修正,如下圖所示

?

其實,在實際使用中我們更傾向于使用兩個不同的接口: 一個IUserBO,一個IUserBiz

單一職責原則定義

應該有且僅有一個原因引起類的變更

單一職責原則的好處:

類的復雜性降低,實現什么職責都有清晰明確的定義

可讀性提高,復雜性降低了,可讀性當然就提高了

可維護性提高,可讀性提高了,當然更容易維護了

變更引起的風險降低.變更是必不可少的,如果接口的單一職責做的好,一個接口修改只對相應的實現類有影響,對其他類無影響,這對系統的擴展性、維護性都有非常大的幫助

---

單一職責原則適用于接口、類,同樣也適用于方法.

---

單一職責原則是非常優秀的,但是在實際使用中受很多因素的制約

建議,接口一定要做到單一職責,類的設計盡量做到只有一個原因引起變化

總結

以上是生活随笔為你收集整理的6大设计原则之单一职责原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。