單一職責原則 如果有一個用戶管理類,類圖如下 我想,任誰也能看的出這個介面設計的有問題,用戶的屬性和用戶的行為沒有分開,應該把用戶的信息抽取成一個業務對象,把用戶的行為抽取成一個業務對象,按照這個思路對類圖進行修正,如下圖所示 其實,在實際使用中我們更傾向於使用兩個不同的介面: 一個IUserBO, ...
單一職責原則
如果有一個用戶管理類,類圖如下
我想,任誰也能看的出這個介面設計的有問題,用戶的屬性和用戶的行為沒有分開,應該把用戶的信息抽取成一個業務對象,把用戶的行為抽取成一個業務對象,按照這個思路對類圖進行修正,如下圖所示
其實,在實際使用中我們更傾向於使用兩個不同的介面: 一個IUserBO,一個IUserBiz
單一職責原則定義
應該有且僅有一個原因引起類的變更
單一職責原則的好處:
- 類的複雜性降低,實現什麼職責都有清晰明確的定義
- 可讀性提高,複雜性降低了,可讀性當然就提高了
- 可維護性提高,可讀性提高了,當然更容易維護了
- 變更引起的風險降低.變更是必不可少的,如果介面的單一職責做的好,一個介面修改只對相應的實現類有影響,對其他類無影響,這對系統的擴展性、維護性都有非常大的幫助
單一職責原則適用於介面、類,同樣也適用於方法.
單一職責原則是非常優秀的,但是在實際使用中受很多因素的制約
建議,介面一定要做到單一職責,類的設計儘量做到只有一個原因引起變化
