1.概念
對類來說的，即乙個類應該只負責一項職責。如類a負責兩個不同職責：職責1，職責2。當職責1需求變更而改變a時，可能造成職責2執行錯誤，所以需要將類a的粒度分解為a1，a2。
2.問題的提出
package com.atguigu.principle.singleresponsibility;
public
class
singleresponsibility1
}// 交通工具類
// 方式1
// 1. 在方式1 的run方法中，違反了單一職責原則
// 2. 解決的方案非常的簡單，根據交通工具執行方法不同，分解成不同類即可
class
vehicle
}
package com.atguigu.principle.singleresponsibility;
public
class
singleresponsibility2
}//方案2的分析
//1. 遵守單一職責原則
//2. 但是這樣做的改動很大，即將類分解，同時修改客戶端
//3. 改進：直接修改vehicle 類，改動的**會比較少=>方案3
class
roadvehicle
}class
airvehicle
}class
watervehicle
}
package com.atguigu.principle.singleresponsibility;
public
class
singleresponsibility3
}//方式3的分析
//1. 這種修改方法沒有對原來的類做大的修改，只是增加方法
//2. 這裡雖然沒有在類這個級別上遵守單一職責原則，但是在方法級別上，仍然是遵守單一職責
class
vehicle2
public
void
runair
(string vehicle)
public
void
runwater
(string vehicle)
//方法2.
//..
//..
//...
}
降低類的複雜度，乙個類只負責一項職責。
提高類的可讀性，可維護性
降低變更引起的風險
通常情況下， 我們應當遵守單一職責原則，只有邏輯足夠簡單，才可以在**級違反單一職責原則；只有類中方法數量足夠少，可以在方法級別保持單一職責原則
設計模式原則 單一職責原則
定義 乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 ...
設計模式原則 單一職責原則
對類來說的，即乙個類應該只負責一項職責。假如類a負責多項職責，當其中一項職責需求發生變更時，可能對其他職責的執行造成影響。例如 類a負責實現 訂單資料持久化 職責 和 使用者資料持久化 職責，那麼當我們需要修改 使用者資料持久化 需求時，由於 糅雜在乙個類裡，可能會對 訂單資料持久化 的職責造成影響...
設計原則 單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...