單一職責原則（全稱：single responsibility princile，簡稱srp），它表示乙個類只具有某種職能，比如人又生理需求（吃、喝、睡）、生活需求（工作、鍛鍊），生理需求和生活需求分別當做兩個類，他們裡邊任意方法的改變都不會影響另乙個類的正常執行，如果乙個類裡邊具有多種職能，那麼意味著一種職能的變化可能會影響另一種職能，那麼這個時候就應當將它們才分成兩個負責不同職能的類。
又比如，我們常用的dao模式，就是採用的單例模式，比如userdao它負責了使用者相關的資料庫相關操作，這裡把一張表作為一種職能。
package com.muzili.principle.singlereposibility;
/** * @author: muzili(李敷斌)
* @date: 2021-01-30
* @version: v0.0.1
* @description: 單一職責模式 案例1
* @analyze: 1.該案例違反了單一職責的設計原則，它的職責分工不明確 乙個方法就描述了交通工具的所有執行的職能 很明顯
* 還可以進行細分 比如可以分為 公路上執行的 天空中執行的 水中執行的
* 優化方案：將特定的執行方式細分到每個類
*/public
class
singleresposibility1
}// 交通工具類
class
vehicle
}
以上**違反了，單一職責的設計原則，可以很明顯的看出交通工具遠遠不止於只能夠在公路上執行，交通工具還可分為在天上飛的、水中游的。
優化方案：
將各種執行方式的交通工具分別實現
package com.muzili.principle.singlereposibility;
/** * @author: muzili(李敷斌)
* @date: 2021-01-30
* @version:
* @description: 單一職責原則 案例2
* @analyze: 1. 案例2符合單一職責的設計原則 2.但是這麼做成本過高，並且需要修改客戶端實現
* 別的單一職責，而實現方法級別的單一職責 這樣做的好處在於防止簡單的邏輯 設計的
* 太過於複雜
*/public
class
singleresposibility2
}//公路交通工具類
class
roadvehicle
}//空中交通工具類
class
airvehicle
}//水中交通工具類
class
wathervehicle
}
以上案例符合單一職能的設計原則。
但是因為業務比較單一且簡單，這樣才分的成本比較高，並且需要修改客戶端的實現。
優化方案：
在方法比較少的時候，可以適當的違反單一職責的設計原則。
package com.muzili.principle.singlereposibility;
/** * @author: muzili(李敷斌)
* @date: 2021-01-30
* @version:
* @description: 單一職責原則 案例3
* @analyze: 1. 案例3在一定程度上違反了單一職責 但是僅僅是違反了類級別的單一職責 在方法層面還是準守了單一職責
*/public
class
singleresposibility3
}//交通工具類
class
vehicle2
public
void
airrun
(string vehicle)
public
void
watherrun
(string vehicle)
}
以上**，違反了類級別的單一職責設計原則，但是遵守了方法級別的單一職責設計原則。
如果在方法比較少的情況下，可以適當的違反單一職責的設計原則，但是如果在乙個類中有方法是與相關具體實現類有關的話，那麼還是需要進行拆分，比如在交通工具類中，此時存在乙個只有轎車才具有的職能 敞篷功能 ，那麼這個時候方法級別的單一職責就不適用了，應當進行職責拆分。
降低類的複雜度，乙個類只負責某一項職責。
提高類的可讀性和可維護性。
降低因變更而引起的風險。
通常情況下，應當嚴格遵守單一職責的設計原則，只有在邏輯非常簡單的情況下，才能夠在**層面違反。即在乙個類中有非常少方法的時候，可以在方法層面保持單一職責的設計原則。
設計模式原則 單一職責原則
定義 乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。問題由來 類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...