# Java 中的 SOLID 原則（含示例） > 原文： [https://howtodoinjava.com/best-practices/5-class-design-principles-solid-in-java/](https://howtodoinjava.com/best-practices/5-class-design-principles-solid-in-java/) 類是任何 Java 應用的構建塊。 如果這些塊不牢固，則建筑物（即應用）將來將面臨艱難時期。 這實質上意味著，當應用范圍擴大或應用在生產或維護中面臨某些設計問題時，編寫得不夠好會導致非常困難的情況。 另一方面，精心設計和編寫的類集可以極大地加快編碼過程，同時減少比較中的錯誤數量。 在本教程中，我們將通過示例討論 Java 中的 **SOLID 原則**，這是 5 種最推薦的設計原則，在編寫類時應牢記。 它們還構成設計應用類時要遵循的[**最佳實踐**](//howtodoinjava.com/category/best-practices/ "java best practices")。 ```java Table Of Contents 1\. Single Responsibility Principle 2\. Open Closed Principle 3\. Liskov's Substitution Principle 4\. Interface Segregation Principle 5\. Dependency Inversion Principle ```  5 個 Java 類設計原則 讓我們一一向下鉆取所有對象。 ## 1.單一責任原則 原則的名稱說明了一切： > “一個類應該只有一個責任” 換句話說，我們應該僅出于一個目的編寫，更改和維護類。 如果是模型類，則它應嚴格只代表一個參與者/實體。 這將使我們能夠靈活地在將來進行更改，而不必擔心更改對另一個實體的影響。 同樣，如果我們正在編寫服務/管理器類，則它應該只包含方法調用的那一部分，而不包含其他任何內容。 甚至沒有與模塊相關的工具全局函數。 最好將它們分開在另一個可全局訪問的類文件中。 這將有助于維護用于該特定目的的類，并且我們可以決定該類僅對特定模塊的可見性。 #### 1.1 單一責任原則示例 在所有流行的 Java 庫中，我們都可以找到很多遵循單一責任原則的類。 例如，在 log4j 中，我們具有使用日志記錄方法的不同類，不同的類是日志記錄級別，依此類推。 在我們的應用級代碼中，我們定義了模型類來表示實時實體，例如人，雇員，帳戶等。這些類中的大多數是 SRP 原則的示例，因為當我們需要更改人的狀態時，才需要修改 一個人的類。 等等。 在給定的示例中，我們有兩個類`Person`和`Account`。 兩者都負有存儲其特定信息的單一責任。 如果要更改`Person`的狀態，則無需修改類`Account`，反之亦然。 ```java public class Person { private Long personId; private String firstName; private String lastName; private String age; private List<Account> accounts; } ``` ```java public class Account { private Long guid; private String accountNumber; private String accountName; private String status; private String type; } ``` ## 2.開閉原則 這是設計應用時應牢記的第二個重要規則。 **開閉原則**指出： > “軟件組件應為擴展開放，但應為修改封閉” 這是什么意思？？ 這意味著我們的類應該這樣設計：每當開發人員想要改變應用中特定條件下的控制流時，他們都需要擴展我們的類并覆蓋某些函數，僅此而已。 如果其他開發人員由于類的約束而無法設計所需的行為，則應重新考慮更改類。 在這里我并不是說任何人都可以改變我們類的整體邏輯，但是他/她應該能夠以軟件允許的無害方式覆蓋軟件提供的選項。 #### 2.1 開閉原則示例 如果我們研究諸如 struts 或 spring 之類的任何良好框架，我們將看到我們無法更改其核心邏輯和請求處理，但僅通過擴展某些類并將其插入配置文件中即可修改所需的應用流。 例如，spring 框架具有類`DispatcherServlet`。 此類充當基于 String 的 Web 應用的**前端控制器**。 要使用此類，我們不需要修改此類。 我們所需要做的就是傳遞初始化參數，然后我們可以按需要擴展其功能。 請注意，除了在應用啟動期間傳遞初始化參數之外，我們還可以覆蓋方法，以通過擴展類來修改目標類的行為。 例如，struts `Action`類被擴展以覆蓋請求處理邏輯。 ```java public class HelloWorldAction extends Action { @Override public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { //Process the request } } ``` ## 3\. 里氏替代原則 該原則是先前討論的打開 - 閉合原則的變體。 它說： > “派生類型必須完全可以替代其基本類型” 這意味著通過擴展我們的類而創建的同級開發人員應該能夠適合應用而不會失敗。 這要求子類的對象的行為與父類的對象相同。 這通常在我們進行運行時類型識別然后將其轉換為適當的引用類型的地方看到。 #### 3.1 里氏替代原則示例 LSP 的一個示例可以是 Spring 框架中的[自定義屬性編輯器](https://howtodoinjava.com/spring-boot/custom-property-editor-example/)。 Spring 提供了屬性編輯器以與對象本身不同的方式表示屬性，例如，從 HTTP 請求參數解析人類可讀的輸入或在視圖層中顯示純 Java 對象的人類可讀的值，例如 `Currency`或`URL`。 Spring 可以為一種數據類型注冊一個屬性編輯器，并且需要遵循**基類** `PropertyEditorSupport`強制的約束。 所以是任何擴展`PropertyEditorSupport`類的類，那么它可以被需要基類的任何地方替換。 例如，每本書都有一個 ISBN 號，它始終是固定的顯示格式。 您可以在數據庫和 UI 中使用獨立的 ISBN 表示形式。 為此，我們可以用以下方式編寫屬性編輯器： ```java import java.beans.PropertyEditorSupport; import org.springframework.util.StringUtils; import com.howtodoinjava.app.model.Isbn; public class IsbnEditor extends PropertyEditorSupport { @Override public void setAsText(String text) throws IllegalArgumentException { if (StringUtils.hasText(text)) { setValue(new Isbn(text.trim())); } else { setValue(null); } } @Override public String getAsText() { Isbn isbn = (Isbn) getValue(); if (isbn != null) { return isbn.getIsbn(); } else { return ""; } } } ``` ## 4.接口隔離原則 這是我最喜歡的原則。 它適用于接口，因為單一責任原則適用于類。 ISP 說： > “不應強迫客戶實現不必要的方法” 舉個例子。 開發人員 Alex 創建了一個接口`Reportable`并添加了兩種方法`generateExcel()`和`generatedPdf()`。 現在，客戶“ A”希望使用此接口，但他打算僅使用 PDF 格式的報告，而不使用 excel。 他將能夠輕松使用該功能嗎？ 沒有。 他將必須實現這兩種方法，其中一種是軟件設計人員要給他增加的負擔。 他或者實現另一種方法，或者將其留空。 這不是一個好的設計。 那么解決方案是什么？ 解決方案是通過破壞現有接口來創建兩個接口。 它們應該像`PdfReportable`和`ExcelReportable`。 這將為用戶提供靈活性，使其僅使用必需的功能。 #### 4.1 接口隔離原則示例 查找 IPS 示例的最佳地方是 Java AWT 事件處理器，用于處理從鍵盤和鼠標觸發的 GUI 事件。 對于每種事件，它都有不同的監聽器類。 我們只需要編寫希望處理的事件處理器即可。 沒有什么是強制性的。 一些監聽器是： * `FocusListener` * `KeyListener` * `MouseMotionListener` * `MouseWheelListener` * `TextListener` * `WindowFocusListener` 任何時候，我們希望處理任何事件，只需找出相應的監聽器并實現它即可。 ```java public class MouseMotionListenerImpl implements MouseMotionListener { @Override public void mouseDragged(MouseEvent e) { //handler code } @Override public void mouseMoved(MouseEvent e) { //handler code } } ``` ## 5.依賴倒置原則 我們大多數人已經熟悉原則名稱中使用的詞語。 DI 原則說： > “依賴抽象而不是具體” 換一種說法。 我們應該以這樣一種方式設計我們的軟件，即可以使用抽象層將各個模塊彼此綁定在一起，從而將各個模塊彼此分離。 #### 5.1 依賴倒置原則示例 Spring 框架中 Bean 配置原則的經典用法。 在 spring 框架中，所有模塊都作為單獨的組件提供，可以通過簡單地將依賴注入到其他模塊中來一起工作。 此依賴關系在 XML 文件中從外部進行管理。 這些獨立的組件在邊界上封閉得非常好，以至于我們可以輕松地在 Spring 之外的其他軟件模塊中使用它們。 這已經通過依賴倒置和開閉原則來實現。 所有模塊僅公開抽象，這對于擴展功能或另一個模塊中的插件很有用。 這些是**五類設計原則**，也稱為 **SOLID 原則**，這是設計應用類別時應遵循的最佳實踐。 學習愉快！