Single Responsibility Principle (SRP)

定義：

對一個類別而言，應該僅有一個引起它變化的原因（職責）。
 

說明：

若一個類別有多重職責，職責之間會互相耦合，一個職責的變化可能會影響該類別完成其他職責的能力。
注意：運用本原則以及其他設計原則必須在實際發生的情況下才使用，不要預先做目前不需要的設計。
 

1. 以變化的參與性決定。

若需求的出現導致類別中所有部份發生變化，代表所有職責可視為同一個職責，不必分離。如果分離反而會導致不必要的複雜度。
相反的，若需求的出現導致類別中某一部份(欄位或函式)發生變化，代表某一部份為不同職責，必須分離，否則會造成僵化性。
 

2. 以變化的頻率和因素決定

以變化頻率而言，商業邏輯經常變化，資料儲存變化較少。
以變化因素而言，商業邏輯和資料儲存的變化因素多不相同。
所以商業邏輯和資料儲存不應該同屬於一個類別。
 

3. 以重構(Refactoring)來分離多重職責

在重構中程式碼的壞味道(bad smell)中，第3點過大的類別(Large Class)，以及第5點發散式變化(Divergent Change)都是關於多重職責的問題。
可使用 Extract Class，Extract Subclass 來切割類別以分離多重職責。
 

4. 在無暇的程式碼(Clean Code)提到，類別若具有多重職責代表該類別內聚力低，為了保持類別的高內聚力，

可以拆解內容過長的方法並觀察拆解後的方法是否具有變化的參與性，若變化總是在某些方法中出現，就把它們提取出來吧。