設計模式是站在設計原則的基礎之上的，所以在學習設計模式之前，有必要對這些設計原則做一下了解。 ### ## **單一職責原則** ### ### 要領 ### **一個類只負責一個功能領域中的相應職責**，就一個類而言，應該只有一個引起它變化的原因，是實現高內聚、低耦合的指導方針； ### ### 解釋 ### #### 高內聚： ### 盡可能類的每個成員方法只完成一件事(最大限度的耦合) 模塊內部的代碼，相互之間的聯系越強，內聚就越高，模塊的獨立性就越好 **比如操作redis緩存，我們可以將一切操作redis緩存的操作都放到同一個類當中，這樣就實現了高內聚的原則** ### #### 低耦合： ### 減少類內部，一個成員方法調用另一個成員方法，不要有牽一發動全身的現象出現，**比如類內部方法和方法之間的操作，我們可以通過中間方法去操作，避免直接調用彼此，因為一個方法就是一個功能，通過中間方法去操作雖然多寫了一個方法但是讓彼此兩個方法解耦**。 ### 類的內部方法之間的調用是無法完全避免耦合的。即使是在同一個類內部，一個方法調用另一個方法，也會存在一定程度的耦合。因為這種調用關系意味著方法之間有依賴關系，修改一個方法可能會影響到另一個方法的行為。 ### 然而，在設計類時，可以盡量減少方法之間的直接調用，從而降低耦合度。可以采用一些設計模式和原則，如**單一職責原則**、依賴倒置原則、以及面向接口編程等，來降低類的內部方法之間的耦合度，提高代碼的靈活性和可維護性 ### ## **開閉原則** ### 對擴展開放，對修改關閉，**在程序需要進?拓展的時候，不能去修改原有的代碼，實現?個熱插拔的效果** ### ## **??替換原則LSP** ### 任何基類可以出現的地?，?類?定可以出現； **在程序中盡量使?基類類型來對對象進?定義，?在運?時再確定其?類類型，??類對象來替換?類對象；** 比如我們在控制器層調用Service的時候都是使用Service的接口，在運行時會去找ISysMenuService接口的實現類里面的方法:  里氏替換原則（Liskov Substitution Principle，簡稱LSP）是面向對象設計中的一個重要原則，由計算機科學家Barbara Liskov提出。該原則要求，任何基類（父類）可以被其子類（派生類）所替換，而程序仍然能夠正確地工作。換句話說，子類必須能夠替換其父類而不影響程序的正確性。 ### **LSP的好處主要體現在以下幾個方面**： 1. **提高代碼的可維護性：** 遵循LSP可以確保子類可以完全替代父類，從而使得代碼更加靈活和可擴展。這樣一來，**如果需要修改或擴展系統的功能，只需添加新的子類或修改現有的子類，而不需要對現有的代碼進行大規模的修改，提高了代碼的可維護性**。 2. **增強代碼的可擴展性：** 符合LSP的設計使得系統更容易擴展。**由于子類可以替換父類，因此可以在不影響原有代碼的情況下引入新的子類來擴展系統的功能，而不必改變現有的代碼**。 3. **提高代碼的可讀性和可理解性：** 符合LSP的設計通常會使得代碼結構更加清晰和直觀。通過合理的類繼承關系，使得代碼更易于理解和閱讀。 4. **減少錯誤：** 符合LSP的設計可以減少因為類之間的替換而導致的錯誤。如果一個子類不能完全替換父類，那么在使用該子類替換父類的情況下可能會導致意料之外的錯誤。 總的來說，遵循里氏替換原則可以帶來更加靈活、可維護和可擴展的代碼，提高軟件系統的質量和可靠性。 ### ## **依賴倒轉原則** ### 是開閉原則的基礎，針對接?編程，依賴于抽象?不依賴于具體； **?層模塊不應該依賴低層模塊，?者都應該依賴其抽象；** ### 依賴倒轉原則（Dependency Inversion Principle，簡稱DIP）是面向對象設計中的一個重要原則，它指導我們如何設計類之間的依賴關系，以實現代碼的靈活性、可擴展性和可維護性。依賴倒轉原則是開閉原則的基礎，是實現開閉原則的重要手段之一。 ### 依賴倒轉原則的核心思想可以歸納為以下幾點： 1. **針對接口編程：** **程序設計應該依賴于抽象接口，而不是具體實現**。抽象接口可以是**接口（Interface）或抽象類（Abstract Class），而具體實現則是實現了這些接口或繼承了這些抽象類的具體類**。 2. **高層模塊不應該依賴于低層模塊：** 在傳統的程序設計中，通常是高層模塊依賴于低層模塊，比如業務邏輯層依賴于數據訪問層。而依賴倒轉原則提倡的是反向依賴關系，**高層模塊和低層模塊都應該依賴于抽象**。 3. **抽象不應該依賴于細節：** **抽象接口或抽象類不應該依賴于具體的實現細節，而是應該由具體的實現細節來依賴抽象**。這意味著具體的實現細節可以靈活地替換或者擴展，而不影響高層模塊的設計和實現。 4. **細節應該依賴于抽象：** **具體的實現細節應該依賴于抽象接口或抽象類，這樣可以保證系統的穩定性和可靠性**。 總的來說，依賴倒轉原則通過引入抽象層，**將高層模塊與低層模塊之間的依賴關系轉化為對抽象的依賴，從而降低模塊之間的耦合度，提高系統的靈活性和可擴展性**。 **依賴倒轉原則有助于更好地利用多態進行開發。依賴倒轉原則鼓勵使用抽象類型而不是具體類型，這使得代碼更具多態性**。 通過依賴抽象而不是具體實現，我們可以在不修改現有代碼的情況下輕松地引入新的實現，并利用多態來替換現有的實現。這樣，代碼更容易擴展和維護，并且可以更靈活地適應變化。 總之，依賴倒轉原則為利用多態性提供了良好的基礎，有助于編寫更加靈活、可擴展和可維護的代碼。 ### **高層模塊和低層模塊的解釋** ### 1. **高層模塊：** 高層模塊通常指的是系統中較為抽象和通用的模塊，它們實現了系統的核心業務邏輯或者提供了系統的核心功能。高層模塊往往是用戶接口、業務邏輯、應用邏輯等層面的模塊。在軟件設計中，高層模塊通常會依賴于低層模塊，而不會暴露太多的實現細節。 ### 2. **低層模塊：** 低層模塊通常指的是系統中較為具體和底層的模塊，它們實現了系統的基礎功能或者提供了系統的基礎支持。低層模塊往往是數據訪問、數據存儲、與外部系統交互等層面的模塊。在軟件設計中，低層模塊通常會被高層模塊所依賴，提供具體的實現細節。 ### ## **接口隔離原則** ### 客戶端不應該依賴那些它不需要的接? **使?多個隔離的接?，?使?單個接?要好，降低類之間的耦合度** ### **接口隔離原則**（Interface Segregation Principle，ISP）是面向對象設計中的一個原則，主要強調“客戶端不應該被強迫依賴它不需要的接口”。這意味著一個類對另一個類的依賴應該建立在最小的接口上。 簡而言之，接口隔離原則要求將接口盡可能地細化，不要設計臃腫龐大的接口，而是應該將大接口拆分成多個小接口，讓客戶端只依賴它們需要的接口。 接口隔離原則的主要目標包括： 1. **將接口粒度細化：將大接口拆分成多個小接口，每個接口只包含客戶端需要的方法**。 2. **避免臃腫的接口：減少接口中的方法數量，避免接口中存在過多的方法，盡量保持接口的單一性。** 3. 提高靈活性：通過接口隔離原則，可以提高系統的靈活性，使得系統更容易擴展、修改和維護。 4. 降低耦合度：遵循接口隔離原則可以降低類與類之間的耦合度，減少對不相關接口的依賴，提高系統的內聚性。 接口隔離原則的實踐方法包括： 1. **將大接口拆分成多個小接口，每個接口只包含特定功能相關的方法**。 2. **根據客戶端的需求設計接口，避免設計過多的通用接口。** 3. **使用接口繼承和實現來實現接口隔離，避免使用過多的方法在同一個接口中。** 4. 定期審查和重構接口設計，確保接口的單一職責和高內聚性。 總之，接口隔離原則是面向對象設計中的重要原則，通過將大接口拆分成多個小接口，可以提高系統的靈活性、降低耦合度，同時也更好地符合單一職責原則。 ### **比如實現一個功能本身只需要實現A這個interface接口里面的2個抽象方法，但是你在A接口里面寫了一大堆的其他用不到的抽象方法就是不合理的，我用不到的就不要寫，哪怕多寫幾個接口進行拆分，哪怕多寫幾個接口的子接口來繼承去實現；** ### ## **迪?特法則** ### 最少知道原則，?個實體應當盡量少地與其他實體之間發?相互作?，使得系統功能模塊相對獨? 類之間的耦合度越低，就越有利于復?，?個處在松耦合中的類?旦被修改，不會對關聯的類造成太?波及 通過引??個合理的第三者來降低現有對象之間的耦合 ### 迪米特法則（Law of Demeter，LoD），又稱最少知識原則（Principle of Least Knowledge，PLK），是面向對象設計中的一個原則，主要強調“一個對象應該對其他對象有最少的了解”。簡單來說，一個對象應該只與其直接的朋友通信，而不要與陌生的對象通信。 具體來說，迪米特法則有以下幾個要點： 1. 一個對象應當對其他對象有限制的了解，它只和朋友對象交流，不和陌生對象交流。**所謂的“朋友”是指：當前對象本身、當前對象的成員對象、方法的參數對象、方法內部創建的對象等**。 2. **避免在方法內部直接訪問其他對象的內部屬性，而應該通過訪問器（getter）來獲取**。 3. **避免在方法內部直接調用其他對象的方法，而應該通過當前對象的成員對象來調用**。 4. 盡量降低類之間的耦合度，每個類盡可能獨立存在，減少類之間的直接依賴關系。 迪米特法則的目的是降低系統的耦合度，提高系統的靈活性和可維護性。通過減少對象之間的直接依賴關系，可以使系統更容易擴展和修改，同時也更容易進行單元測試和重構。 在實際應用中，可以通過以下方法來遵循迪米特法則： 1. **盡量將方法的訪問權限設置為私有或受保護，限制方法的調用范圍**。 2. **盡量將類的成員屬性設置為私有或受保護，并通過訪問器來訪問**。 3. **盡量減少對象之間的直接依賴關系，通過依賴注入、接口隔離等設計模式或者參數傳遞來實現**。 4. 定期審查和重構代碼，確保符合迪米特法則，降低系統的耦合度。 總之，迪米特法則是面向對象設計中的重要原則，通過限制對象之間的直接交流，可以降低系統的耦合度，提高系統的靈活性和可維護性。 ### **關于迪?特法則的精準介紹** ### 一個對象應該對其他對象保持最少的了解 類與類關系越密切，耦合度越大 迪米特法則(Demeter?Principle)又叫最少知道原則，即一個類對自己依賴的類知道的越少越好。也就是說，對于被依賴的類不管多么復雜，都盡量將邏輯封裝在類的內部。對外除了提供的public?方法，不對外泄露任何信息 **迪米特法則還有個更簡單的定義：只與直接的朋友通信 直接的朋友：每個對象都會與其他對象有耦合關系，只要兩個對象之間有耦合關系，我們就說這兩個對象之間是朋友關系。耦合的方式很多，依賴，關聯，組合，聚合等。其中，我們稱出現成員變量，方法參數，方法返回值中的類為直接的朋友，而出現在局部變量中的類不是直接的朋友。也就是說，陌生的類最好不要以局部變量的形式出現在類的內部** ### 具體的一個迪米特法則可參考地址：https://www.cnblogs.com/snail-learn-code/p/14361559.html