如果有乙個使用者管理類,類圖如下
我想,任誰也能看的出這個介面設計的有問題,使用者的屬性和使用者的行為沒有分開,應該把使用者的資訊抽取成乙個業務物件,把使用者的行為抽取成乙個業務物件,按照這個思路對類圖進行修正,如下圖所示
其實,在實際使用中我們更傾向於使用兩個不同的介面: 乙個iuserbo,乙個iuserbiz
應該有且僅有乙個原因引起類的變更
類的複雜性降低,實現什麼職責都有清晰明確的定義
可讀性提高,複雜性降低了,可讀性當然就提高了
可維護性提高,可讀性提高了,當然更容易維護了
變更引起的風險降低.變更是必不可少的,如果介面的單一職責做的好,乙個介面修改只對相應的實現類有影響,對其他類無影響,這對系統的擴充套件性、維護性都有非常大的幫助
單一職責原則適用於介面、類,同樣也適用於方法.
單一職責原則是非常優秀的,但是在實際使用中受很多因素的制約
建議,介面一定要做到單一職責,類的設計盡量做到只有乙個原因引起變化
設計原則之單一職責原則
無論是什麼設計原則，全部都是圍繞 專案的生命週期 和 高內聚，低耦合 這兩個關鍵字。定義 單一職責原則 srp single responsibility principle 又稱單一功能原則，它規定了乙個類應該只有乙個發生變化的原因，即乙個類只負責一項職責。字面上很好理解，但是如果做起來卻很難做到...
設計原則之單一職責原則
什麼是單一職責原則 定義 有且僅有乙個使介面或類產生變化的原因。也就是說我們使類或介面變化，只能有乙個理由。但是在實際開發的過程中，我們很容易做到介面單一職責，很難做到類單一職責。例如 我們以查詢資料，處理資料，返回資料為例。如果我們這樣設計乙個介面 public inte ce iuserbo p...
設計原則 單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...