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

乙個類應該只負責一項職責。

如類 a 負責兩個不同職責：職責 1，職責 2。當職責 1 需求變更而改變 a 時，可能造成職責 2 執行錯誤，所以需要將類 a 的粒度分解為 a1，a2

以交通工具為案例進行講解

1

public
class
singleresponsibility1 8}
910class
vehicle 
14 }

第一行的輸出結果就出現了乙個違反常識的錯誤，在vehicle類的run方法中違反了單一職責原則，飛機不屬於陸地交通工具，因此導致run方法的職責多樣化了，出現了上述錯誤

解決方案：根據交通工具執行方式的不同區分成不同的類即可

於是我們將vehicle類分解成roadvehicle、airvehicle，watervehicle，分別代表在陸地，空中，水中的交通工具，得到下面的**：

1

public
class
singleresponsibility2 10}
1112
class
roadvehicle 16}
1718
class
airvehicle 22}
2324
class
watervehicle 
28 }

這樣就符合我們的常識了，也遵循了單一職責原則，但是這種方式同樣存在一些問題，將乙個類分解為三個類的話**改動較大，會增加系統記憶體的開銷

解決方案：不分解vehicle類，直接修改vehicle類中的方法即可

於是我們根據交通工具不同的執行方式分別在vehicle類中寫出對應的方法，得到以下**：

1

public
class
singleresponsibility3 8}
910class
vehicle2 
1415
public
void
runair(string name) 
1819
public
void
runwater(string name) 
22 }

執行結果跟剛才是一樣的，但是這裡沒有例項化三個類的物件，只是例項化了乙個類，呼叫了這個類中不同的方法，減小了系統記憶體開銷的同時也遵循了單一職責原則，兩全其美

降低類的複雜度，乙個類只負責一項職責。

提高類的可讀性，可維護性

降低變更引起的風險

通常情況下，我們應當遵守單一職責原則，只有邏輯足夠簡單，才可以在**級違反單一職責原則；只有類中方法數量足夠少，可以在方法級別保持單一職責原則

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

singleresponsibility 對類而言，乙個類只負責一項職責。如果類a負責兩個不同的職責 職責1和職責2 當職責1需求變更改變a時，可能就會造成職責2執行錯誤 所以需要將類a的粒度分解為a1，a2a.降低類的複雜度，乙個類只負責一項職責 b.提高類的可讀性，可維護性 c.降低變更引起的風...

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

responsibility principle srp 乙個類或者模組只負責完成乙個職責 或者功能 類和模組的兩種理解 把模組看作比類更加抽象餓概念，類也可以看作模組 把模組看作壁壘更加粗粒度的 快，模組中包含多個類，多個類組成乙個模組 不是。不管是應用設計原則還是設計模式，最終的目的還是提高 的...

設計模式七大原則之單一職責原則

單一職責原則 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。也就是類a 如果負責兩項任務t1和t2，如果當t1職責需求變更需要修改類a，可能會對t2導致影響或故障 這個時候我們就需要將任務t1和t2分離開來，遵循單一原則，既修改t1，t2不受影響 舉個例子 class anim...