就乙個類而言，應該僅有乙個引起它變化的原因。如果a類負責兩個不同職責：當職責1變更的時候可能會造成職責2的錯誤，所以需要將類a的粒度分解為a1，a2。
我們以交通工具為案例講解
//方式1：
// 交通工具類
class
vehicle;}
public
static
void
main
(string[
] args)
對於交通工具vehicle類來說，run方法違反了單一職責原則，需要對vehicle進行功能拆分，於是我們公升級為方式2。
//方式2： 交通工具類拆分
class
airvehicle
}class
roadvehicle
}public
static
void
main
(string[
] args)
這樣做遵守單一職責原則，但是類本身並不複雜，這樣做的改動很大，即將類分解，同時修改客戶端。有沒有適合簡單類的單一職責方案呢？
class
vehicle2
public
void
runair
(string vehicle)
public
void
runwater
(string vehicle)
}public
static
void
main
(string[
] args)
這種修改方法沒有對原來的類做大的修改，只是增加方法,雖然沒有在類這個級別上遵守單一職責原則，但是在方法級別上，仍然是遵守單一職責。
單一職責原則注意事項和細節：
1）乙個類只負責一項職責，降低類的複雜程度，提高可讀性。
2）減少修改類帶來的風險。
3）通常情況下，我們應遵守單一職責原則。只有類足夠簡單，類中方法足夠少才可以在方法級別保持單一職責(實際已經違反了單一職責，如果該類日後需要繼續擴充套件則必須按照類級別重新分離類的職責)。
設計模式之單一職責原則
關於單一職責原則，我想大家都聽過不少，今天來看看這個原則具體是什麼，有哪些好處使我們需要選擇遵守它呢？一 定義 乙個類只能因為乙個原因而修改。怎麼理解呢？簡單來說，乙個類只能實現一項功能，或者換句話說，乙個類只有乙個職責，只有當這個職責發生變化，它才會被修改，說白了就是乙個類質感乙個類該幹的事。二 ...
設計模式之單一職責原則
首先就名字而言不難想象，單一必定是只能有乙個，而這個乙個指的是什麼呢，那就是乙個職責。而職責通俗易懂來說就是乙個功能，乙個類只能有乙個功能，而如果有兩個及以上的功能就不再符合單一職責原則了。就好比乙個水壺，它的功能就只是裝水，而不存放別的東西，那它就滿足了單一職責原則。優點有複雜度低，或者說簡單明瞭...
設計模式原則 單一職責原則
定義 乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 ...