設計模式 單一職責原則

2022-09-09 01:12:19 字數 1554 閱讀 4161

設計模式-單一職責原則

單一職責原則使用的是建立型模式

建立型模式對類進行抽象

重點,建立型模式能夠將物件的建立和和物件的使用分離。即使用建立型模式能夠使得物件的建立,物件的使用分離。重點在於分離。

設計模式有六大基本原則,單一職責原則,黎克特制替換原則,依賴倒置原則,介面隔離原則,迪公尺特法則,開閉原則。

其中建立型模式符合單一職責原則。

即srp 使用者角色管理等模組,使用的是rbac模型

rbac 一種以角色為儲存的控制,使用rbac 不賦予許可權,賦予角色,例如windows的使用者管理,使用的是賦予角色,對使用者進行管理,這種方式為rbac,目的在於使得使用者和許可權分離。

設計乙個使用者管理,依據單一職責模型,設計以下的結構。

該結構定義一些管理使用者的,增加使用者的一些內容,寫入乙個介面中,然後進行實現。

該介面具有以上的問題。

使用者的屬性(是否為註冊使用者,vip使用者等等),使用者的行為(增加使用者,刪除使用者)沒有分開。

該介面一團糟!

應該使用者的資訊,使用者的行為抽取為乙個介面,然後乙個介面繼承這兩個介面

更改的如下所示

why? 為什麼要分離,因為單一職責原則,當使用單一職責原則的時候,每個介面,每個類需要承擔單一的職責,不應該承擔過多的原則,易於維護

核心 ,乙個介面只有乙個原則!乙個介面只能負責一件事情,只有乙個原因能引起其變化

這個介面包含兩個職責,協議管理和資料傳送。

dial和chat為通話,該通話和撥打**,使用了同時都和協議有關係,如果要更改協議,那麼這兩個介面的內容都需要進行更改。由於乙個介面存在兩個職責,所以該介面需要劃分為兩個介面

此時存在乙個關聯關係,撥打**和協議的實現,兩者之間存在關聯關係,此關聯關係為靜態關聯

這個類圖完全符合單一職責的原則。每個狀態只決定一件事情。每個狀態的更改只改變一件事情。

好處 複雜度降低 可讀性提高 可維護性增強 變更引起的風險降低(因為變更的時候如果每個介面只負責乙個單一的原則,那麼乙個介面的修改對其他沒有影響,這樣降低了整體的複雜度)

刀就是刀,叉就是叉,1就是1,0就是0.沒有中間態,每個方法也同樣的適用於單一原則,每個方法也同樣的只承擔乙個內容。乙個作用。

this is sometimes hard to see

這個有時候很難說!

對介面盡量做到單一原則,類的做到引起乙個原因引起的變化。

www.iming.info

設計模式原則 單一職責原則

定義 乙個物件應該只包含單一的職責,並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說,就是乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1,職責p2。當由於職責p1需求發生改變而需要修改類t時,有可能會導致原本執行正常的職責p2功能發生故障。解決方案 ...

設計模式原則 單一職責原則

對類來說的,即乙個類應該只負責一項職責。假如類a負責多項職責,當其中一項職責需求發生變更時,可能對其他職責的執行造成影響。例如 類a負責實現 訂單資料持久化 職責 和 使用者資料持久化 職責,那麼當我們需要修改 使用者資料持久化 需求時,由於 糅雜在乙個類裡,可能會對 訂單資料持久化 的職責造成影響...

設計模式原則 單一職責原則

1.概念 對類來說的,即乙個類應該只負責一項職責。如類a負責兩個不同職責 職責1,職責2。當職責1需求變更而改變a時,可能造成職責2執行錯誤,所以需要將類a的粒度分解為a1,a2。2.問題的提出 package com.atguigu.principle.singleresponsibility p...