單一職責到底是什么？十分鐘帶你掌握!
在日常開發工作中，經常會聽到有經驗的技術念叨xxx需要注意單一職責，那么，什么是單一職責？如何做才能保證職責單一？這篇文章幫你分析透。
什么是單一職責？
關于單一職責，看過很多版本的解釋，這里歸納最常見的三個版本：
- 版本一：一個類只有一個引起變化的原因
- 版本二：一個類都應該只負責一項職責
- 版本三：一個類只能干一件事情
哪個版本的解釋比較合理呢？
單一職責原則，英文是：Single responsibility principle（SRP），是 Robert C. Martin提出的 SOLID原則中的一種，所以，我們先看看 作者對單一職責原則的描述，這里摘取了作者關于單一職責的原文：
The Single Responsibility Principle (SRP) states that
each software module should have one and only one reason to change.原文翻譯為：單一職責原則指出，任何一個軟件模塊都應該有一個且只有一個修改的理由。
定義看起來很嚴謹，但似乎和現實是相沖突的，因為軟件設計本身就是一門關注長期變化的學問，變化是軟件中最常見不過的問題，在現實環境中，軟件系統為了滿足用戶和所有者的要求，勢必會作出各種修改，而系統的用戶或者所有者就是該設計原則所指的"被修改的原因"。
于是乎，作者又重新把單一職責描述為：
The single responsibility principle states that every module
or class should have responsibility over a single part of
the functionality provided by the software, and that
responsibility should be entirely encapsulated by the class.原文翻譯為：單一職責原則指出，每個模塊或類應該只負責軟件所提供功能的一部分，并且這個職責應該完全被該類封裝。
在這個定義中，每個模塊或者類只負責軟件的一部分功能，那這一部分是多少呢？這部分功能是否可以包含不同類型的行為呢？比如，電商中的訂單和物流都可以叫做電商的一部分功能，但是他們在業務意義上顯然是不同的領域，因此，該定義缺乏了定性。
于是乎，作者再次修改了單一職責的定義：
Each module should only be responsible to one actor.原文翻譯為：任何一個軟件模塊都應該只對某一類行為者負責
這個定義，只要是能歸結成一類的行為，都可以屬于某個模塊的功能，這樣定義看起來更符合現實業務的語意。
軟件模塊是什么？
在上述單一職責幾個定義中都提到了軟件模塊，那么，軟件模塊到底是什么呢？
軟件模塊（Software Module）是指軟件系統中的一個獨立單元，它包含一組相關的功能和數據，這些模塊是通過封裝數據和功能來實現的，以便實現更高的代碼復用性、可維護性和可擴展性。通常具有以下特點：
- 獨立性：模塊是相對獨立的代碼單元，可以單獨開發、測試和部署。模塊的獨立性提高了系統的靈活性，使得各個模塊可以獨立演化和更新，而不影響其他模塊。
- 封裝性：模塊內部的數據和實現細節對外界隱藏，只通過公開的接口與其他模塊進行交互。封裝性提高了代碼的安全性和可維護性。
- 職責單一：每個模塊通常只負責一組相關的功能，這有助于遵循單一職責原則，使得模塊更加易于理解和維護。
- 可重用性：模塊設計得當，可以在不同的項目中重復使用，提高了開發效率和代碼質量。
- 可替換性：模塊通過標準化的接口與外界交互，可以在不影響其他部分的前提下替換或更新某個模塊。
為了更好地說明軟件模塊，這里以一個電商系統為例，它可能包含以下幾個模塊：
(1) 用戶管理模塊：
- 功能：處理用戶的注冊、登錄、個人信息管理等。
- 接口：提供用戶注冊、登錄、信息更新等服務。
(2) 訂單管理模塊：
- 功能：處理訂單的創建、更新、查詢等。
- 接口：提供訂單創建、訂單狀態更新、訂單查詢等服務。
(3) 支付處理模塊：
- 功能：處理訂單的支付、退款等。
- 接口：提供支付請求、支付狀態查詢、退款等服務。
(4) 庫存管理模塊：
- 功能：處理商品的庫存查詢、更新等。
- 接口：提供庫存查詢、庫存更新等服務。
單一職責示例
為了更好的說明任何一個軟件模塊都應該只對某一類行為者負責這個定義，下面我們通過2個 Java反例來進行演示。
反例1
假設有一個 Employee員工類并且包含以下 3個方法：
public class Employee {
// calculatePay() 實現計算員工薪酬
public Money calculatePay();
// save() 將Employee對象管理的數據存儲到企業數據庫中
public void save();
// postEvent() 用于促銷活動發布
public void postEvent();
}剛看上去，這個類設計得還挺符合實際業務，員工有計算薪酬、保存數據、發布促銷等行為，但是這 3個方法對應三類不同的行為者，計算薪酬屬于財務的行為，保存數據屬于數據管理員的行為，發布促銷屬于銷售的行為。
因此，Employee類將三類行為耦合在一起，違反了單一職責原則。假如一個普通員工不小心調用了calculatePay()方法，把每個員工的薪酬計算成了實際工資的2位，那可想而知這是一個災難性的問題。
如果增加新需求，要求員工能夠導出報表，因此，需要在 Employee類中增加了一個新的方法，代碼如下：
// 導出報表
void exportReport();接著需求又一個一個增加，Employee類就得一次一次的變動，這會導致什么結果呢？
一方面，Employee類會不斷地膨脹；另一方面，可能業務需求完全不同，卻始終需要在同一個 Employee類上改動，合理嗎？
聯想一下你的日常開發，是否也有這樣的設計？把很多不同的行為都耦合到同一個類中，然后隨著業務的增加，該類急劇膨脹，最后無法維護。
該如何解決這種問題呢？
解決這個問題的方法有很多，特定的行為只能由特定的行為者來操作，因此，需要把 Employee類拆解成 3種行為者（財務、數據管理員、銷售），Employee類拆分之后的代碼如下：
// 財務行為
public class FinanceStaff {
public Money calculatePay();
}
// 數據管理員行為
public class TechnicalStaff {
public void save();
}
// 銷售行為
public class OperatorStaff {
public String postEvent();
}反例2
假設需要開發一個電商系統，其中有一個 Order訂單類，負責處理訂單的創建、訂單的支付以及訂單的通知，代碼如下：
public class Order {
public void createOrder() {
// 訂單創建邏輯
}
public void processPayment() {
// 支付處理邏輯
}
public void sendNotification() {
// 發送通知邏輯
}
}在上述代碼中，Order類同時承擔了訂單創建、支付處理和通知發送的職責，違反了單一職責原則，因為一個類有多個引起變化的原因。
為了遵循SRP，我們需要將不同的職責分離到不同的類中，因此可以創建三個類：Order類負責訂單創建，PaymentProcessor類負責支付處理，NotificationService類負責通知發送，每個類都只承擔一個職責，從而遵循了單一職責原則。代碼如下：
public class Order {
public void createOrder() {
// 訂單創建邏輯
}
}
public class PaymentProcessor {
public void processPayment(Order order) {
// 支付處理邏輯
}
}
public class NotificationService {
public void sendNotification(Order order) {
// 發送通知邏輯
}
}上面2個示例代碼的拆分都遵從了原則：因相同原因而發生變化的事物聚集在一起，因不同原因而改變的事物分開。這就是單一職責的真正體現，也是定義內聚和耦合的一種方式。
總結
從作者 Robert C. Martin對單一職責的 3次定義變更，我們可以看出：
- 單一職責原則本質上就是要理解分離關注點。
- 單一職責原則可以應用于不同的層次，小到一個函數，大到一個系統。
- 軟件設計也不可能一成不變。
回歸到實際的工作中，我們可以把一個系統模塊看作一個單一職責的行為者，比如：訂單系統只關注訂單相關的行為，交易系統只關注交易相關的行為，我們也可以把類作為一個單一職責的行為者，比如：訂單類，把訂單相關的 CRUD聚合在一起，支付類，把支付相關的信息聚合在一起。
因此，任何一個軟件模塊都應該只對某一類行為者負責這個定義才更適合單一職責。
最后，單一職責原則是面向對象設計的重要原則之一，它可以提高代碼的可維護性、可讀性和可擴展性，在日常開發中，遵循 SRP可以有效地降低類之間的耦合度，提高系統的穩定性和靈活性，從而寫出更高質量的代碼。
