單一責任原則 · HowToDoInJava 中文系列教程

# 單一責任原則 > 原文： [https://howtodoinjava.com/design-patterns/single-responsibility-principle/](https://howtodoinjava.com/design-patterns/single-responsibility-principle/) **單一責任原則**（SRP）指出，軟件組件（通常為類）必須僅具有一個職責。類負有全部責任這一事實意味著，類只負責一件具體的事情，因此，我們可以得出結論，類只有一個改變的理由。它是 5 個著名的 [SOLID 原則](https://howtodoinjava.com/best-practices/5-class-design-principles-solid-in-java/)之一。 > 一個類只有一個改變的理由。還有另一種看待這一原則的方法。如果在查看一個類時，我們發現相互排斥且彼此不相關的方法，則它們是必須分解為較小類的不同職責。請記住，較小的類總是更好。 ## 1.動機如果出于各種原因必須對類進行修改，則意味著抽象不正確，并且該類承擔了太多責任。基本上，我們希望在所有情況下都避免具有多個職責的對象（通常稱為**神對象**，因為它們知道的太多或超出了他們應有的知識）。這些對象將不同的行為（大多數是不相關的）組合在一起，從而使它們難以維護。 ## 2.單一責任原則示例要了解**單責任原則的真實示例**，我們可以看一下 JDK 代碼和其他流行的庫，例如 Log4J，Spring 框架等。Log4J 代碼具有使用日志記錄方法的不同類，不同的類是日志記錄級別等等。在 Spring 框架中，類實際上很小，通常只執行一兩個相關操作。讓我們再舉一個自己的例子，以更好地理解什么是單一責任原則。 #### 2.1 問題為了理解 SRP 原則，我們假設我們正在開發涉及與員工一起工作的應用。我們有一個接口`IEmployeeStore`，它的實現`EmployeeStore`具有以下方法。 ```java public interface IEmployeeStore { public Employee getEmployeeById(Long id); public void addEmployee(Employee employee); public void sendEmail(Employee employee, String content); } ``` ```java public class EmployeeStore implements IEmployeeStore { @Override public Employee getEmployeeById(Long id) { return null; } @Override public void addEmployee(Employee employee) { } @Override public void sendEmail(Employee employee, String content) { } } ``` 在任何普通應用上，上述類似乎都不錯。使用`EmployeeStore`，可以獲取/添加員工并向他們發送電子郵件。現在假設產品發布后，我們要求電子郵件內容可以是兩種類型，即 HTML 和文本。該類支持僅文本內容。你會做什么？解決此問題的一種方法是創建另一種方法`sendHtmlEmail()`，但是當我們被要求支持為兩種內容類型發送電子郵件的不同協議時會發生什么。整體類看起來非常丑陋，難以閱讀和維護。而且總是有機會在修改期間，某些開發人員可以更改用于共享員工方法的獲取/添加員工方法的邏輯。 #### 2.2 SRP 原則的解決方案要解決此問題，我們必須退出電子郵件功能，以分離專門處理電子郵件相關功能的接口和類。這樣，我們可以確定其他功能不會受到影響。基于我們的假設，我們可以抽象出兩個接口`IEmailSender`和`IEmailContent`。第一個接口負責電子郵件的發送過程，第二個接口負責傳遞電子郵件的內容及其類型。重構的類在下面給出。 ```java public interface IEmployeeStore { public Employee getEmployeeById(Long id); public void addEmployee(Employee employee); } ``` ```java public class EmployeeStore implements IEmployeeStore { //inject in runtime private IEmailSender emailSender; @Override public Employee getEmployeeById(Long id) { return null; } @Override public void addEmployee(Employee employee) { } } ``` ```java public interface IEmailSender { public void sendEmail(Employee employee, IEmailContent content); } ``` ```java public class EmailSender implements IEmailSender { @Override public void sendEmail(Employee employee, IEmailContent content) { //logic } } ``` ```java public interface IEmailContent { } ``` ```java public class EmailContent implements IEmailContent { private String type; private String content; } ``` 現在，如果要更改電子郵件功能，我們將僅更改`EmailSender`類。員工 CRUD 操作的任何更改將僅在`EmployeeStore`中發生。一種能力的任何改變都不會錯誤地改變另一種能力。它們也不太容易閱讀和維護。 ## 3.好處 #### 3.1 易于理解和維護當類僅做“一件事情”時，其接口通常具有較少數量的方法（和成員變量），這些方法很容易解釋。它使代碼更易于閱讀和理解。當需要更改應用行為時，與類職責相關的更改是相當隔離的。它減少了破壞軟件其他無關區域的機會。它使代碼更易于維護。 #### 3.2 改善的可用性如果一個類有多個職責，并且為了某個職責而需要在應用的其他部分中使用它，則可能不利地暴露其他職責，而這是不希望的。它可能導致應用中不良行為，例如，安全和數據隱私問題。如果該類嚴格遵循 **SRP 原則**，則不會暴露出不必要的功能，這將使該類更加可用，而不必擔心會產生不利影響。 ## 4\. 結論 **單責任原則設計模式**對代碼的適應性具有巨大的積極影響。與不遵循該原則的等效代碼相比，符合 SRP 的代碼導致產生了更多的類，這些類更小且指向范圍更廣。 SRP 的實現主要是通過抽象接口后的代碼并將不相關功能的職責委托給運行時恰好在接口后的實現來實現的。閱讀更多： [關注點分離](https://en.wikipedia.org/wiki/Single_responsibility_principle)