1、原則的定義
2、原則設計的初衷
3、能解決哪些問題
4、有哪些場景可以使用
單一職責原則，英文名single responsibility principle,縮寫為srp。乙個類或者模組只負責完成乙個職責（或者功能）。也就是說，不要設計大而全的類，要設計粒度小，功能單一的類。換個角度來講就是，乙個類包含兩個或者兩個以上業務互不相干的功能，那我們就說它職責不夠單一，應該將它差分為多個功能單一，粒度更細的類。
上面是從類的角度來描述單一職責原則，同樣對於乙個模組，乙個函式亦是如此。
「高內聚，松耦合」是乙個非常重要的設計思想，能夠有效的提高**的可讀性和可維護性，縮小功能改動導致的**改動範圍。
高內聚，就是指功能相近的**放到同乙個類中，不相近的**不要放到同乙個類中，相近的共功能往往會被同時修改，放到同乙個類中，修改會比較集中，修改的範圍相對的也就會越小，**容易維護。
松耦合，在**中，類與類之間的依賴關係簡單清晰。即使兩個類有依賴關係，乙個類改動**不會或者很少導致被依賴的類的**的改動。
單一職責原則主要是為**的編寫提供指導意見，需要我們主觀的去判斷模組、類、方法是否滿足單一職責原則，來實現**的高內聚。提高**的可讀性和可維護性。
評判乙個類的職責是否組個單一，並沒有乙個非常明確的，可以量化的標準。不同的場景，不同階段的需求背景，不同的業務層面，對同乙個類的職責是否單一，可能會有不同的判定結果。實際上，在真正的軟體開發過程中，為避免過度設計，我們可以先寫乙個粗粒度的類，滿足業務需求。隨著業務的發展，如果粗粒度的類越來越龐大，**越來越多，這個時候，我們就可以講這個粗粒度的類，拆分成幾個更細粒度的類。這就是所謂的重構。
比起需要主觀的的去思考類是否職責單一，下面的幾條判斷標準可能更具有指導意義。
也就是說上面的幾種情況可能不滿足單一職責原則。需要對其進行拆分。
上面是從類的角度來判斷職責是否單一，同樣對於乙個模組，乙個函式也需要考慮其是否滿足單一職責原則。
我們通過單一職責原則避免設計大而全的類，避免將不相關的功能耦合在一起，來提高類的內聚性。但是如果拆分的過細，實際上會適得其反，反而降低**的內聚性，也會影響**的可維護性，這需要根據具體場景，具體分析，就同上面所述的一樣，同乙個類，在不同的場景，其單一職責原則的判定結果也會不一樣。
參考：設計模式之美--王爭
設計原則 單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...
設計原則 單一職責原則
在物件導向程式設計領域中，單一職責原則 single responsibility principle 規定每個類都應該有乙個單一的功能，並且該功能應該由這個類完全封裝起來。所有它的 這個類的 服務都應該嚴密的和該功能平行 功能平行，意味著沒有依賴 乙個類或者模組應該有且只有乙個改變的原因。乙個具體...
設計原則 單一職責原則
設計原則 單一原則 如何理解單一職責原則乙個類或者模組只負責完成乙個職責 或者功能 注意,這個原則描述的物件包含兩個,乙個是類 class 乙個是模組 module 關於這兩個概念，在專欄中，有兩種理解方式。一種理解是 把模組看作比類更加抽象的概念，類也可以看作模組。另一種理解是 把模組看作比類更加...