單一職責原則(srp): 就乙個類而言,應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多,就等於把這些職責耦合在一起,乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計,當變化發生時,設計會遭到意想不到的破壞。
從分離的角度,分享對單一職責原則的思考:
前後端分離
介面與實現分離
業務與系統分離
公共與邏輯分離
開發與生產分離
資料模型和處理分離
優點:降低類的複雜度;
提高類的可讀性,因為類的職能單一,看起來比較有目的性,顯得簡單;
提高系統的可維護性,降低變更程式引起的風險。
變更引起的風險降低。變更是必然的,如果單一職責原則遵守得好,當修改乙個功能時,可以顯著降低對其他功能的影響。
缺點:如果一味追求這個單一職責,從而造成冗餘**或**的浪費。
為什麼要遵守srp呢?(
1)可以減少類之間的耦合
如果減少類之間的耦合,當需求變化時,只修改乙個類,從而也就隔離了變化;如果乙個類有多個不同職責,它們耦合在一起,當乙個職責發生變化時,可能會影響到其他職責。
(2)提高類的復用性
單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說,即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1,職責p2。當由於職責p1需求發生改變而需要修改類t時,有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2,使t1完成職責p1功能,t...
單一職責原則
單一職責原則 乙個類,只有乙個引起它變化的原因。應該只有乙個職責。每乙個職責都是變化的乙個軸線,如果乙個類有乙個以上的職責,這些職責就耦合在了一起。這會導致脆弱的設計。當乙個職責發生變化時,可能會影響其它的職責。另外,多個職責耦合在一起,會影響復用性。例如 要實現邏輯和介面的分離。對於user類,裡...
單一職責原則
問題由來 一心二用,效率降低 類t負責兩個不同的職責 職責p1,職責p2。當由於職責p1需求發生改變而需要修改類t時,有可能會導致原本執行正常的職責p2功能發生故障。解決方案 專注做某件事情 遵循單一職責原則。分別建立兩個類t1 t2,使t1完成職責p1功能,t2完成職責p2功能。這樣,當修改類t1...