單一職責原則

軟體設計模式（design pattern），又稱設計模式，是一套被反覆使用、多數人知曉的、經過分類編目的、**設計經驗的總結。使用設計模式是為了可重用**、讓**更容易被他人理解、保證**可靠性、程式的重用性。

單一職責原則(srp)：乙個類只做一件事兒,乙個方法也應該只做一件事兒.

如下**就違背了單一職責原則

public

class
animal
public
void
eat()
public
void
action()
}

static

void main(string
args)
console.readkey();
}

幾乎每加乙個動物就要加乙個分支... ...

將職責進行拆分,重構**

public

abstract
class
animal
public
abstract
void
eat();
public
abstract
void
action();
}

///

///每個類做自己的事兒
///public
class
animalowl : animal
public
override
void
eat()
吃蟲子");
}public
override
void
action()
可以飛");
}}

///

///每個類做自己的事兒
///public
class
animalpanda : animal
public
override
void
eat()
吃竹子");
}public
override
void
action()
可以跑");
}}

static

void main(string
args)
console.readkey();
}

拆分之後,職責變的單一。閱讀簡單，易於維護。擴充套件公升級，減少修改，直接增加類。簡單--穩定--強大。

如果乙個類承擔的職責過多,這些職責在程式中就會過度耦合,不利於擴充套件。

總結：方法層面：方法裡有多個分支(if{} else

{}),還可能擴充套件變化,最好拆成多個方法。

介面層面:將不同業務的介面進行獨立。

類層面：乙個類只做一件事兒。

類庫層面:把專案拆分為多個類庫。

專案:乙個專案應該職責要清晰（客戶端/管理後台/後台服務/定時任務/... ...）

單一職責原則

定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類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...